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I.  INTRODUCTION 


The  purpose  of  this  chapter  is  to  provide  an  overarching  synopsis  of  this  project. 
We  accomplish  this  by  summarizing  the  history  and  evolution  of  the  current  materiel 
requirements  documents,  identifying  the  primary  research  question  and  supporting 
questions,  describing  the  scope  of  the  project  and  the  summarized  research  methodology, 
and  outlining  the  organization  of  this  project.  Our  objective  in  this  chapter  is  to  clearly 
define  the  intent  of  this  project  and  the  strategy  to  answer  the  research  questions. 

A.  PREFACE 

The  Army’s  requirements  generation  process  (RGP)  has  undergone  multiple 
evolutionary  changes  since  the  beginning  of  the  Global  War  on  Terror  (GWOT).  These 
changes  have  resulted  from  many  different  causes.  First,  the  National  Security  Strategies 
(NSS)  over  the  past  decade  have  dictated  many  incremental  changes  to  the  process  and 
documents  that  support  the  process.  Second,  there  have  been  organizational  changes  in 
the  Army’s  structure  and  formation.  Third,  there  have  been  ongoing  initiatives  for 
improvements  and  enhancements  to  streamline  processes.  Fourth,  there  have  been  shifts 
in  the  holistic  mentality  of  the  Department  of  Defense  (DoD)  to  become  more  joint  and 
unified  between  each  of  the  Services.  Furthermore,  there  continue  to  be  changes  to  the 
existing  RGP  perpetuated  by  the  government  as  adaptations  are  made  in  response  to  ever- 
changing  worldwide  threats. 

The  United  States  (U.S.)  Joint  Forces  have  persistently  revised  their  materiel 
requirements  to  meet  the  urgent  needs  of  warfighters  and  to  fulfill  capability  gaps.  Prior 
to  the  Joint  Capabilities  Integration  Development  System  (JCIDS),  each  branch  of 
Service  possessed  its  own  unique  system  to  validate  materiel  requirements  and  the 
acquisition  process  used  to  interface  with  requirements  and  the  associated  documents. 
The  Army’s  process  had  been  very  bottom-up  driven.  The  Army’s  training  schools 
identified  the  warfighters’  need,  and  Army  Headquarters  (HQ)  would  acquire  those 
validated  needs.  After  2003,  a  new  mindset  began  to  take  precedence  within  the  Joint 
Staff  and  Combatant  Commands.  An  emphasis  on  joint  thinking  became  a  necessity 
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across  the  defense  community.  The  requirements  generation  process  had  to  be  top-down 
driven  in  order  to  fully  embrace  joint  thinking.  By  switching  to  top-down  direction,  the 
Joint  Staff  and  Combatant  Commands  created  greater  oversight,  which  provides 
commonality  across  the  Services.  This  top-down  flow  ensures  clearly  communicated 
strategic  guidance  and  concept  of  operations  (CONOPS).  The  approach  for  top-down 
thinking  is  depicted  in  Figure  1.  Nevertheless,  the  implementation  of  change  would 
prove  to  be  challenging  and  defining  the  most  efficient  process  would  be  an  arduous  task. 


Guidance 


Capability  Based 
Assessment 


Capabilities-based  identification 
of  needs  combines  the  JOpsC 
with  analysis:  Overlay  what  we 
have  with  what  we  need  to  do. 


Reconciliation 
&  Recommendations 


jcros 

Recommendations 
Capability  Needs 
DOTMLPF  Changes 


Decision 

and 

Action 


DCR 

Science  & 

Implementation 

Technology 

Planning, 
Programming, 
Budgeting  and 
Execution 


Figure  1.  Top-Down  Approach  for  Capability  Needs  (From  CJCS,  2007,  p.  A-3) 


1.  The  Past 

In  October  2001,  the  U.S.  began  combat  operations  in  Afghanistan  in  response  to 
the  9/11  attacks.  Years  later,  in  May  2003,  the  U.S.  committed  to  its  second  combat  front 
in  Iraq.  As  with  any  war,  the  enemies  began  augmenting  their  tactics,  techniques,  and 
procedures  (TTPs)  based  on  observed  actions  of  the  people  they  were  fighting.  Change 
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of  their  TTPs  drove  the  U.S.  warfighters’  demand  for  enhanced  equipment  to  assist  in 
neutralizing  and  defeating  the  enemy’s  new  TTPs.  The  Army  had  to  respond  with  full 
force  and  vigilant  tenacity.  The  Army,  as  well  as  the  whole  DoD  community,  had  to 
drastically  evolve  their  RGP  in  order  to  meet  the  needs  of  the  warfighters.  By  order  of 
the  Chairman,  Joint  Chiefs  of  Staff,  the  Army  shifted  from  its  own  requirements 
generation  system  (RGS)  and  transitioned  to  the  DoD’s  Joint  Capabilities  Integration  and 
Development  System.  As  a  result,  the  materiel  capabilities  documents  (MCDs)  used  in 
JCIDS  replaced  the  Anny’s  materiel  requirements  documents  (MRDs)  used  in  the  RGS. 

This  change  occurred  at  a  volatile  time  for  the  DoD.  Implementing  change  was 
difficult  in  a  stable  organization  like  the  DoD  that  had  been  wedded  to  a  process  that  had 
existed  for  over  a  decade.  Implementing  change  in  the  midst  of  the  beginning  of  two 
campaigns  would  prove  to  be  much  more  difficult  and  somewhat  dismptive  to  the  DoD  culture. 

2.  The  Present 

There  are  many  stakeholders  and  key  personnel  involved  in  the  RGP  that 
contribute  directly  to  the  writing  of  MRDs.  However,  there  are  also  indirect  factors  that 
drive  and  define  the  language  of  these  documents.  For  instance,  the  enemy  has  always 
been  relevant  as  one  of  the  primary  influencers  on  requirements  for  new  equipment. 
Additionally,  dramatic  advancements  in  technology  have  resulted  in  the  acquisition  of 
new  materiel  and  the  associated  new  documents.  The  idea  of  needs  in  the  RGS  has  been 
replaced  by  the  concept  of  capabilities  in  JCIDS.  Exact  materiel  solutions  (new 
equipment/system)  to  meet  desired  capability  should  not  be  specifically  requested. 
Additionally,  capabilities  can  often  be  met  without  a  materiel  solution.  Simply,  the 
concept  of  needs  was  replaced  with  capabilities  because  the  DoD  did  not  feel  that  it  was 
efficient  for  the  warfighter  to  ask  for  a  materiel  solution.  Asking  for  a  specific  materiel 
solution  would  only  create  multiple  solutions  and  redundancies  in  equipment.  Instead, 
the  warfighter  is  to  request  capabilities. 

A  simplified  example  of  this  is  if  users  state  that  they  need  an  M224  60-mm 
Lightweight  Mortar.  This  may  not  be  the  best  solution.  The  user  should  request  a  system 
under  50  lbs.  that  may  be  disassembled,  man  portable,  operated  from  the  ground,  fire 
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multifunctional  munitions,  including  high  explosive  rounds,  smoke  rounds,  and 
illumination  rounds,  and  has  a  maximum  effective  range  not  less  than  3,000  meters.  This 
allows  supporting  stakeholders  to  identify  what  is  the  best  and  most  efficient  solution  that 
can  meet  all  of  the  users’  capability  needs. 

Technological  advancements  on  both  friendly  and  enemy  sides  have  also 
compelled  the  DoD  to  revise  their  MRDs  into  systems  of  systems  and  family  of  systems. 
According  to  the  Office  of  the  Deputy  Under  Secretary  of  Defense  for  Acquisition  and 
Technology,  Systems  and  Software  Engineering  (ODUSD  [A&T]  SSE),  systems  of 
systems  bring  “added  complexity  due  to  multiple  system  lifecycles  across  acquisition 
programs,  involving  legacy  systems,  systems  under  development,  new  developments,  and 
technology  insertion;  typically  have  stated  capability  objectives  upfront  which  may  need 
to  be  translated  into  formal  requirements”  (Dahmann,  Baldwin,  &  Rebovich,  2011,  p.  3). 
The  DoD  recognizes  that  the  future  of  technology  is  difficult  to  predict.  Nonetheless,  the 
DoD  also  realizes  that,  even  with  this  unpredictability,  the  processes  that  initiate  materiel 
solutions  must  project  potential  future  capabilities  insertions.  Furthermore, 
unconventional  warfare  requires  unconventional  materiel  solutions.  Improvised 
explosive  devices  (IEDs),  Ruchnaya  Kumulyativnaya  Granata  3  (RKG-3),  and 
homemade  explosives  (HMEs)  have  led  to  U.S.  forces  developing  capability 
requirements  for  equipment  to  improve  survivability.  Therefore,  the  United  States  has 
had  to  heighten  its  ability  to  answer  the  warfighters’  demands  to  counter  the  enemy’s 
abilities  to  conduct  kinetic  operations  on  the  battlefield.  Thus,  the  state  of  the  world 
continues  to  have  an  effect  on  the  future  of  the  RGP  and  the  associated  MRDs. 

3.  The  Future 

The  RGP  and  MRDs  are  facing  another  potential  change  due  to  the  state  of  the 
nation.  The  U.S.  government  has  projected  the  GWOT  troop  drawdown  to  occur  in  2014. 
The  president  of  the  United  States  and  the  secretary  of  defense  (SECDEF)  have  given 
guidance  through  their  security  strategies  for  the  military’s  future  fighting  force  to  shift 
its  focus  to  air  and  sea  superiority.  In  addition,  Congress  has  directed  the  Office  of 
Management  and  Budget  (OMB)  through  the  Budget  Control  Act  (BCA)  of  2011,  to 
annually  reduce  the  defense  budget  by  $54.7  billion  from  2013  through  2021  (Heniff, 
Rybicki,  &  Mahan,  2011). 
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These  directives  pose  new  constraints  and  forces  that  may  greatly  impact  the  U.S. 
Army.  First,  budget  reductions  have  caused  the  Army  to  begin  executing  a  50,000- 
soldier  reduction  plan  to  be  complete  by  2017,  and  potentially  downsizing  the  Army’s 
combat  formations  from  47  active  duty  brigade  combat  teams  (BCTs)  to  as  few  as  32 
active  BCTs.  The  end- state  composition  of  the  Army  has  yet  to  be  defined.  Second,  the 
unit-level  modified  table  of  organization  and  equipment  (MTO&E)  of  this  future  Army  is 
even  further  away  from  final  delineation.  Last,  the  projected  threat  and  shift  in  emphasis 
on  air  and  sea  superiority  will  undoubtedly  affect  the  Army’s  future  missions.  These 
constraints  will  change  the  future  modernized  equipment  structure  of  the  joint  military 
and  the  U.S.  Army.  The  Army  must  project  and  plan  for  this  impending  conversion. 
Aftereffects  of  a  shift  in  force  structure  and  MTO&E  may  lead  to  a  change  with  the  RGP. 
A  change  with  the  RGP  would  also  impact  the  MRDs  and  force  the  documents  to  change. 

4.  The  Way  Ahead 

The  U.S.  Army  must  posture  itself  for  this  transformation  if  it  wishes  to  minimize 
the  effects  of  change  on  its  operations.  The  Army  recognizes  that  its  equipment  must  be 
modernized  and  at  the  forefront  of  technology  if  it  is  to  remain  the  world’s  most  powerful 
land  force.  Conversely,  the  Army  recognized  that  RGS  MRDs  were  inefficient  and 
ineffective.  MRDs  lacking  in  efficiency  and  effectiveness  lead  the  Army’s  acquisition 
programs  down  a  path  of  not  meeting  the  required  capabilities.  “If  we  always  did  what 
we  always  do,  we  will  always  get  what  we  always  got.  We  need  tough  examination  of 
the  assumptions  of  our  past  and  real  ideas  for  change  that  solve  issues,”  said  Paul  Mann 
(personal  communication,  October  25,  2012),  SES/Assistant  Director  Land  Warfare  & 
Munitions  at  OSD  AT&L  and  former  Joint  Program  Manager  for  Mine-Resistant 
Ambush  Protected  (MRAP)  vehicles. 

The  Army  recognizes  that  in  order  to  improve  its  requirements  documents,  it  must 
change  in  four  key  functions,  as  outlined  by  the  Army  Acquisition  Review  Board  in  2011: 

1.  Realign,  resource  and  focus  its  requirements  and  acquisition 

professionals  on  their  raison  d’etre  and  associated  core  competencies,  i.e., 

Training  and  Doctrine  Command’s  timely  delivery  of  requirements; 

Program  Executive  Office  (PEO)  and  Program  Manager  delivery  of 
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products  meeting  the  requirement  on  cost  and  on  schedule;  and  Army 
staffs  that  are  accountable  for  enabling  the  requirement  to  be  met 

2.  Involve  all  stakeholders  collaboratively  in  requirements  development, 
development  planning  and  acquisition  solicitation,  rather  than  just 
critiquing  others 

3.  Realistically  assess  and  manage  risk,  and  follow  more  tailored 
evolutionary  acquisition  strategies  with  associated  reductions  in  steps, 
time  and  documentation  to  provide  new  systems 

4.  Improve  the  number,  quality  and  accountability  of  the  people  essential 
to  the  acquisition  of  equipment  and  systems  needed  for  our  servicemen 
and  women  to  be  equipped,  trained  and  ready.  (Army  Acquisition  Review 
Board,  2011,  p.  iv) 

More  efficient  and  effective  MCDs  are  crucial  in  the  support  of  key  functions  1, 
2,  and  3.  Identified  requirements  may  be  met  by  numerous  means  by  the  Army.  They 
may  be  answered  by  changing  doctrine,  organization,  training,  and  TTPs.  If  requirements 
are  not  achieved  by  these  methods,  the  acquisition  of  new  equipment  or  systems  is 
needed.  The  RGP  is  essential  to  a  functional  acquisition  process.  Three  primary  decision 
support  systems  interact  to  develop  materiel  capabilities:  (1)  the  Planning,  Program, 
Budget,  and  Execution  (PPBE)  process;  (2)  the  Defense  Acquisition  System;  and  (3)  the 
JCIDS  (see  Figure  1).  The  RGP  falls  within  the  JCIDS  process.  Thus,  without  an 
efficient  RGP  and  supporting  efficient  and  effective  requirements  documents,  the 
overarching  acquisition  process  cannot  be  efficient. 

Cohesive  MCDs  will  reduce  unnecessary  redundancies  and  will  allow 
requirements  to  be  delivered  in  an  efficient  and  effective  manner.  Gaining  stakeholders’, 
such  as  the  warfighter’s,  buy  in  and  input  early  in  the  MCDs  will  provide  better 
collaboration  and  will  reduce  scrutiny.  Finally,  effective  MCDs  are  the  tools  to  deliver 
defined  requirements  from  the  warfighter  to  fill  capability  gaps  with  materiel  and  non¬ 
materiel  solutions  to  the  warfighter.  While  there  are  many  other  facets  in  the  defense 
acquisition  system,  MCDs  are  a  crucial  aspect  that  must  continually  evolve  to  refine  a 
better  way  ahead  for  a  more  efficient  RGP. 
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B.  PURPOSE 


The  purpose  of  this  project  is  to  analyze  the  characteristics  of  Army  materiel 
requirement  documents  that  support  material  development  up  to  Low  Rate  Initial 
Production  (LRIP)  within  the  Integrated  Defense  Acquisition,  Technology,  and  Logistics 
Life  Cycle  Management  System.  We  look  at  the  necessary  documents  that  facilitate  the 
creation  of  a  materiel  solution,  MRDs  and  MCDs  used  to  develop  the  prototypes  of  the 
HMMWV,  M-ATV,  or  JLTV.  In  this  project,  our  analysis  focuses  on  the  documents 
used  in  both  the  old  RGS  and  the  new  JCIDS  processes,  and  identifies  distinctive 
elements  of  efficiency  and  effectiveness,  as  shown  in  Figure  2. 


Figure  2.  Effectiveness  vs.  Efficiency  (After  Croxford,  2012) 

In  this  project,  we  identify  potential  changes  to  the  MCDs  or  the  Army’s  RGP 
(JCIDS)  that  will  result  in  more  efficiency  and  effectiveness,  based  on  our  analysis  of 
these  documents. 

C.  RESEARCH  QUESTION 

Our  objective  in  this  research  project  is  to  answer  the  following  question:  What 
should  be  the  Army’s  major  considerations  for  the  revisions  of  future  materiel 
requirements  documents? 

To  aid  us  in  answering  the  primary  research  question,  we  utilized  these  supporting 
questions: 
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Question  1:  What  makes  requirement  documents  efficient  and  effective,  or 
inefficient  and  ineffective  for  the  stakeholders  who  facilitate  the  RGP? 

Question  2:  What  key  differences  exist  in  the  documents  from  the  old  RGS 
process  compared  to  the  new  JCIDS  process,  and  why  were  these  changes  made 
during  this  transition? 

Question  3:  Does  future  change  need  to  be  evolutionary  or  revolutionary? 

D.  SCOPE 

We  analyze  the  requirements  documents  of  two  specific  Army  RGP  systems  in 
the  project.  The  name  of  materiel  requirements  documents  (MRD)  was  changed  to 
materiel  capability  documents  (MCD)  during  the  transition  to  the  Joint  Capabilities 
Integrated  Development  System  (JCIDS).  For  our  project,  we  used  the  term 
“requirements  documents”  as  a  generic  term  for  both.  The  first  RGP  system  was  the 
Requirements  Generation  System  (RGS),  which  was  used  prior  to  2003  and  used  MRDs. 
These  documents  are  the  mission  needs  statement  (MNS),  the  initial  operational 
requirements  document  (ORD),  and  the  production  ORD.  The  second  RGP  system  is  the 
JCIDS,  established  in  May  2003,  which  uses  MCDs  and  is  augmented  by  the  Joint  Urgent 
Operations  Needs  Statement  (JUONS)  process.  The  JCIDS  documents  are  the  initial 
capabilities  document  (ICD),  the  capability  development  document  (CDD),  and  the 
capability  production  document  (CPD).  Furthermore,  the  project  team  analyzed  the  type 
of  change  for  a  future  requirements  generation  process  and  requirements  documents.  The 
identified  changes  are  supplemented  with  effective  methods  and  techniques  to  implement 
these  system  changes  into  the  U.S.  Army.  Finally,  the  project  team  identified  the  benefits 
of  recommended  changes. 

In  Figure  3,  we  identify  the  project’s  scope  where  MRDs  and  MCDs  affect  the 
Defense  Acquisition  System  (DAS)  which  is  outlined  by  the  DoD  Instruction  5000.02 
(DoD,  2008).  The  figure  identifies  the  periods  of  time  during  which  the  RGS  and  JCIDS 
were  in  effect.  Although  there  are  three  major  DoD  decision  support  systems  (i.e., 
JCIDS,  DAS,  PPBE),  in  this  project  we  focus  only  on  the  requirements  documents 
interface  between  the  Acquisition  Management  System  (AMS)  and  the  RGS  as  well  as 
the  interface  between  the  DAS  and  JCIDS.  The  figure  represents  these  interactions  by 
the  shaded  cross-hatched  sections.  Specifically,  in  the  project,  we  examine  and  analyze 
the  requirements  documents  used  to  communicate  between  the  two  decision-support 
systems  from  both  eras;  this  is  represented  by  Figure  3. 
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RGS  CRITICAL  INTERACTION  MODEL 

JCIDS  CRITICAL  INTERACTION  MODEL 

(PRE  -  JUN  2003) 

(POST -JUN  2003) 

Figure  3.  Scope  of  Analysis  in  Relation  to  the  DoD  Decision  Support  Systems 

(After  CJCS,  2001,  p.  A-l) 


One  additional  note  pertaining  to  the  scope  of  our  project  is  with  the  research  and 
data  collected.  Our  project  analyzes  the  requirements  documents  from  the  perspective  of 
program  managers  and  other  personnel  working  within  a  program  office. 

E.  RESEARCH  METHODOLOGY  SUMMARY 

In  this  research  project,  the  project  team  undertook  three  primary  focuses.  We 
focus  on  the  evolution  of  the  requirements  generation  documents  prior  to  the  Global  War 
on  Terror  in  Afghanistan  and  Iraq,  the  ongoing  processes,  including  the  JUONS  process, 
that  have  supported  the  war,  and  the  merger  of  both  processes  to  develop  future 
requirements.  Within  these  areas  of  focus,  we  used  a  qualitative  approach  for  document 
comparison.  Another  focus  is  a  comparative  analysis  between  three  separate  wheeled 
vehicles  that  were  developed  to  meet  the  requirements  from  three  separate  requirement 
generation  processes. 

The  project  team  utilized  past  and  present  policy  and  procedures,  analyzed  studies 
and  reports  produced  during  both  RGP  periods  of  RGS  and  JCIDS,  reviewed  past  and 
present  classes  and  trainings  provided  to  the  defense  acquisition  workforce,  and 
conducted  interviews  with  governmental  subject-matter  experts  (SMEs)  who  have 

worked  and  lived  through  this  period  of  time.  All  data  were  collected  through  public 
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records  and  all  interviews  adhered  to  the  Naval  Postgraduate  School  Institutional  Review 
Board  for  the  Protection  of  Human  Subjects,  Executive  Decision  Memorandum  dated 
April  29,  2005. 

F.  ORGANIZATION  OF  MBA  PROFESSIONAL  REPORT 

This  project  report  is  organized  in  the  following  order:  the  background  of  the 
requirements  generation  process,  research  methodology,  case  studies  of  the  materiel 
requirements  documents  of  the  past  and  the  present,  results,  and  conclusions.  In  the 
background  chapter,  we  provide  an  overview  of  the  RGPs  of  the  RGS  and  JCIDS  and 
their  respective  requirements  documents.  In  the  research  methodology  chapter,  we 
provide  detailed  information  on  how  the  study  was  conducted.  In  the  next  chapter,  we 
present  the  case  studies  and  results.  In  the  case  study,  we  provide  an  overview  of 
evolutionary  change  versus  revolutionary  change  and  compare  and  analyze  the 
requirements  documents  of  three  Army  wheeled-vehicle  platforms  that  have  been 
affected  by  the  different  requirements  generation  processes  with  respect  to  Better  Buying 
Power  2.0  and  efficiency  and  effectiveness.  In  the  results,  we  provide  the  findings  from 
the  comparative  analysis.  Finally,  in  the  conclusions  chapter,  we  provide  answers  to  each 
of  the  proposed  questions,  techniques  to  effectively  implement  the  project’s 
recommendations,  and  the  benefits  of  implementing  the  recommendations. 

G.  CHAPTER  SUMMARY 

In  this  chapter,  we  gave  an  overview  of  the  background  of  the  development  of  this 
project’s  topic,  the  purpose  of  this  project,  and  the  primary  question  and  supporting 
questions  that  this  project  intends  to  answer.  Additionally,  in  this  introduction,  we 
provided  the  scope  of  the  project,  the  methodology  that  the  project  team  utilized,  and  the 
organization  of  the  project. 

In  the  background  chapter  (Chapter  II),  we  supply  a  synopsis  for  both  the  RGS 
and  JCIDS  RGP  systems.  In  addition  to  the  synopsis,  we  provide  an  overview  of  the 
requirements  documents  we  analyzed  for  this  project.  Finally,  we  describe  the  key 
stakeholders  that  author,  approve,  and  execute  the  MRDs  and  MCDs. 
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II.  BACKGROUND 


In  this  chapter,  we  provide  an  overview  of  the  information  required  to  understand 
the  Army’s  requirement  documents  and  their  significance  in  the  requirements  generation 
process.  We  accomplish  this  by,  first,  describing  the  purpose  as  well  as  the  evolution  of 
the  RGP  from  the  Requirements  Generation  System  to  the  current  Joint  Capabilities 
Integration  and  Development  System.  Second,  we  provide  a  summary  of  the  requirement 
documents  and  their  associated  formats.  Last,  we  describe  the  key  stakeholders  who 
author,  staff,  approve,  and  execute  the  requirement  documents. 

A.  INTRODUCTION 

In  this  project,  we  analyze  the  requirements  documents  that  are  utilized  to  create  a 
materiel  solution.  Requirements  documents  are  the  essential  records  that  articulate  needs 
or  requirements,  and  then  refine  such  needs  or  requirements  for  a  materiel  solution  if  a 
non-materiel  solution  cannot  be  identified.  Each  requirement  document  has  its  specific 
designated  authors,  and  the  document  is  staffed  for  validation,  approved  by  the  respective 
authority,  and  executed  within  the  Army’s  acquisition  process.  The  requirements 
documents  we  discuss  in  this  project  were  used  during  the  requirements  generation 
processes  of  the  RGS  (pre-June  2003)  and  the  JCIDS  (post-June  2003).  The  documents 
we  analyzed  in  this  project  are  listed  in  Table  1. 


Table  1.  Documents  Analyzed  for  Project 


RGS  Materiel  Requirements  Documents 

JCIDS  Materiel  Capabilities  Documents 

•  Mission  Needs  Statement  (MNS) 

•  Operational  Requirements  Document 
(ORD)— Initial 

•  Operational  Requirements  Document 
(ORD) — Revised 

•  Initial  Capability  Document  (ICD) 

•  Capability  Development  Document 
(CDD) 

•  Capability  Production  Document  (CPD) 

•  Joint  Urgent  Operational  Need  Statement 
(JUON) 

Our  overview  begins  with  the  concepts  on  which  these  requirements  documents 
were  developed.  These  concepts  are  the  purpose  of  each  document,  the  RGPs  in  which 
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they  were  used,  the  time  period  in  which  they  were  used,  why  the  RGS  documents  were 
replaced  by  the  JCIDS  documents  and  how  they  evolved,  and  how  they  are  embedded  in 
the  DoD  5000  Defense  Acquisition  System  (DAS).  We  have  aligned  these  requirements 
documents  in  Figure  4  to  illustrate  their  interface  with  the  Defense  Acquisition  System. 


Figure  4.  The  Defense  Acquisition  System  With  Associated  Requirements  Documents 

(After  DoD,  2008,  p.  12) 


Figure  4  is  composed  of  several  components  to  depict  and  guide  the  examination 
process  we  used  in  this  project.  We  emphasize  three  specific  segments  in  the  figure.  The 
first  segment  is  the  top  portion.  This  area  outlines  the  simplified  version  of  the  DoDI 
5000.02  (DoD,  2008)  DAS  and  identifies  key  milestones  that  occur  between  the  specific 
phases  of  the  process.  The  five  phases  are  (1)  Materiel  Solution  Analysis,  (2) 
Technology  Development,  (3)  Engineering  and  Manufacturing  Development,  (4) 
Production  and  Deployment,  and  (5)  Operations  and  Support.  In  this  project,  we  review 
the  requirements  documents  that  pertain  to  Phases  1,  2,  3  and  4,  which  take  a  program 
through  Milestone  (MS)  A,  B,  and  C. 

The  lower  portion  of  Figure  4  outlines  the  requirements  documents  within  their 
respective  RGP.  In  the  RGS  (upper  lane)  and  JCIDS  (lower  lane)  sections  are  several 
document-shaped  icons.  Each  icon  represents  a  requirements  document  and  is  shown 
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where  it  would  be  implemented  within  the  acquisition  process.  Requirements  documents 
shifted  in  names,  details,  and  locations  within  the  acquisition  process  as  the  transition 
was  made  from  RGS  to  JCIDS.  The  figure  shows  the  past  and  present  documents,  and 
how  the  documents  are  nested  into  the  DAS.  Additionally,  by  depicting  the  requirements 
documents  within  the  DAS,  we  have  been  able  to  better  understand  the  transformation 
from  one  document  to  another. 

We  analyzed  the  documents  required  once  a  need/capability  is  identified  (prior  to 
MS  A)  to  the  time  when  a  materiel  solution  is  about  to  undergo  LRIP.  Once  CJCSI 
3170. 1C  (CJCS,  2003)  cancelled  CJCSI  3170.01B  (CJCS,  2001)  in  2003,  ICD  replaced 
the  MNS,  CDD  replaced  the  ORD-Initial,  and  CPD  replaced  the  ORD-revised.  Both 
MNS  and  ICD  are  required  before  the  decision  point  to  move  into  Materiel  Solution 
Analysis  phase.  The  ORD-Initial  is  required  before  a  materiel  solution  can  enter  MS  A. 
However,  the  ICD  moves  forward  through  MS  A,  and  the  CDD  is  not  required  until  the 
pre-EMD  review  and  prior  to  entering  MS  B.  Both  ORD-revised  and  CPD  are  required 
prior  to  entry  into  MS  C  and  LRIP.  A  detailed  description  of  each  requirements 
document  is  provided  in  this  chapter. 

B.  REQUIREMENTS  GENERATION  PROCESSES 

The  Requirements  Generation  Process  (RGP)  is  the  documentation  used  by  the 
Army  to  provide  materiel  and  non-materiel  solutions  to  fill  capability  gaps.  The  process 
identifies  a  system  need  or  capability  which  brings  an  acquisition  program  from  a  mere 
thought  to  an  actual  product  that  is  derived  from  the  original  need  /  capability.  (How  the 
Army  Runs  2011-2012,  p.  46).  The  RGP  has  been  in  a  state  of  constant  evolution  since 
2000.  This  evolution  has  resulted  from  transformation  of  the  Army’s  force  structure, 
advancement  in  technology,  the  state  of  the  world,  and  threats  to  national  security.  Since 
2000,  the  Army  has  realized  that  transformation  is  critical  in  order  to  accomplish  present 
and  future  missions  and  strategic  objectives.  In  2002,  the  Army  RGP  was  required  to 
first  address  non-material  solutions  by  considering  doctrine,  training,  leader  development, 
organization,  materiel,  and  soldier  (DTLOMS).  The  RGP  consisted  of  four  distinct 
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phases:  Phase  1,  Definition  Phase;  Phase  2,  Documentation  Phase;  Phase  3,  Validation 
Phase;  and  Phase  4,  Approval  Phase  (U.S.  Army  War  College,  2002). 

During  this  time  period  (early  2000s),  the  Army  was  still  operating  under  a  force 
structure  and  MTO&E  based  on  a  Cold  War  mentality.  The  MTO&E  brought  clear 
expectations  to  the  requirements  for  each  level  of  organization  within  the  Army.  The 
MTO&E’s  priority  focused  on  equipping  heavy  brigades  with  armored  track  vehicles  like 
Abrams  Tanks,  Bradley  Fighting  Vehicles,  and  Armored  Personnel  Carriers.  However,  a 
heavy-force  conflict  has  not  occurred  since  the  Gulf  War  and  Operation  Desert  Storm 
(1990-1991).  Conflicts  ensuing  after  the  Gulf  War  and  Operation  Desert  Storm  were 
Somalia  (1992-1995)  and  the  Balkans  (1991-2001),  but  these  operations  used  nowhere 
near  the  heavy  force  of  Desert  Storm.  The  scale  of  these  operations  neither  caused  nor 
influenced  any  significant  changes  in  how  the  Department  of  Defense  (DoD)  conducted 
RGPs  for  materiel  solutions. 

Requirements  started  as  a  force  development  process  to  fill  equipment  shortfalls 
within  the  Army’s  formation.  Identification  of  material  solutions  to  fulfill  needs  would 
require  a  lengthy  and  arduous  process.  Then,  going  through  the  acquisition  process  often 
took  up  to  15  years  before  the  material  solution  was  fielded  to  soldiers.  The  Requirement 
Generation  System  (RGS)  pre-June  2003  was  very  bottom-up  focused.  Bottom-up  focus 
means  the  lower  echelons  state  what  they  need  or  capabilities  they  want  to  have  with 
regard  for  only  their  particular  functional  area.  A  bottom-up  focus  generally  leads  to 
unsynchronized  actions  and  in  acquisition  can  lead  to  systems  that  are  incompatible  with 
systems  in  other  functional  areas.  This  creates  constraints  on  the  material  development 
system.  Acquisition  programs  may  end  up  being  incompatible  with  other  systems  or  may 
only  serve  one  specific  function  within  the  specified  area.  However,  with  a  “big  picture” 
outlook,  control  can  be  placed  on  needs  and  capabilities  to  ensure  compatibility  and 
usefulness  across  all  of  the  different  functional  areas  within  the  Army. 

General  (GEN)  Eric  Shinseki,  the  chief  of  staff  of  the  Army  (CSA)  in  2000,  took 

operational  and  tactical,  technical,  and  procedures  (TTPs)  lessons  learned  from  the 

Balkans  and  recognized  the  importance  of  transforming  the  current  Army’s  formation. 

GEN  Shinseki’s  concept  of  transformation  was  to  transition  the  legacy  force  into  an 
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interim  force  and,  ultimately,  into  an  objective  force.  GEN  Shinseki  identified  that 
transformation  was  not  limited  only  to  the  Army’s  physical  composition  (force  structure) 
but  applied  also  to  its  doctrine  (Burlas,  2003).  A  holistic  change  with  regards  to  how  the 
Army  conducted  operations  was  required  to  achieve  a  successful  and  seamless 
modification  that  would  not  interrupt  the  Army’s  ongoing  missions  (Shinseki,  2000). 
“Transformation  isn’t  just  about  shiny  new  equipment — it’s  also  about  changing  systems 
and  processes”  (Burlas,  2003).  As  a  result,  the  Army’s  RGP  would  also  need  to 
transform  to  support  the  Army’s  initiatives  of  a  highly  mobile  force  that  had  the  same 
lethality  as  a  heavy  force.  The  transformation  would  have  to  be  top-down  driven. 
Ultimately,  GEN  Shinseki ’s  concept  for  modifying  the  RGP  faced  great  resistance  and 
slow  change. 

The  events  of  9/1 1  followed  by  the  GWOT  increased  the  need  for  the  acquisition 
process  to  generate  requirements  more  quickly.  Capability  gaps  increased  as  well  as  the 
need  to  fill  these  gaps  for  the  warfighter  in  order  for  them  to  execute  their  missions  on  the 
battlefield.  It  became  the  DoD’s  decision  to  revolutionize  the  RGP.  Army  leadership 
and  the  Joint  Staff  leadership  recognized  that  the  branch-centric  approach  with  a  sole 
acquisition  focus  for  specific  functional  areas  was  no  longer  sufficient  to  meet 
warfighters’  needs.  Branch-centric  mindsets  and  functions  were  inadequate  to  execute 
combat  operations.  “Requirements  needed  to  be  determined  holistically  and  incorporate 
a  greater  perception  of  warfighting  concepts  focusing  on  the  future  and  to  provide  the 
military  with  viable  requirements”  (U.S.  Army  War  College,  2002,  p.  5-5).  The  DoD 
evolved  the  RGS  into  the  JCIDS.  The  change  from  RGS  to  JCIDS  provides  the  DoD 
with  the  means  to  emphasize  and  structure  the  requirements  generation  process  to  begin 
looking  at  programs  from  a  Joint  perspective  for  all  of  the  different  Services. 
Consequently,  the  evolution  of  the  RGS  to  JCIDS  resulted  in  the  modification  of  the 
requirements  documents  that  facilitated  materiel  solutions. 

The  Army’s  process  has  evolved  over  the  years;  however,  the  basic  concept  of 
identifying  system  capabilities  has  always  been  a  three-step  procedure.  First,  it  begins 
with  the  identification  of  a  broad  need  or  capability  gap.  Second,  non-materiel  or 
materiel  solutions  are  recommended  and  every  suggested  proposal  undergoes  evaluation 
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to  determine  if  it  fulfills  the  need  or  capability.  Third,  a  course  of  action  is  selected  and 
refined  with  key  performance  parameters  (KPPs).  Figure  5  illustrates  this  concept. 


Figure  5.  Identification  of  Systems  Capabilities  Flow  Chart  (After  DAU,  n.d.,  p.  4) 


Each  of  these  basic  Army  steps  has  an  associated  requirement  document  based  on 
the  time  frame  of  the  specific  RGP  (RGS  or  JCIDS)  that  is  being  followed:  At  Step  1, 
Very  Broad  Needs  uses  the  MNS  or  ICD;  at  Step  2,  Performance  Objectives  uses  the 
ORD-Initial  or  the  CDD;  and  at  Step  3,  System-Specific  Requirements  uses  the  ORD- 
Revised  or  CPD.  It  is  necessary  in  our  study  to  understand  the  difference  between  the 
RGS  and  JCIDS,  and  how  the  RGP  has  evolved. 

1.  Requirements  Generation  System  (Pre-June  2003) 

We  begin  our  study  chronologically  based  on  time  and  occurrence  within  the 
RGP.  The  starting  point  is  RGS,  outlined  in  the  Chairman  of  the  Joint  Chiefs  of  Staff 
Instruction  (CJCSI)  Requirements  Generation  System ,  or  CJCSI  3170.01B  (CJCS,  2001), 
dated  April  15,  2001.  This  was  then  cancelled  by  CJCSI  Joint  Capabilities  Integration 
and  Development  System,  or  CJCSI  3170.01C  (CJCS,  2003),  dated  June  24,  2003. 
Additionally,  the  three  DoD  decision  support  systems  during  this  time  period,  shown  in 
Figure  3,  were  the  RGS,  the  Acquisition  Management  System,  and  the  Planning, 
Programming,  and  Budgeting  System  (PPBS;  CJCS,  1999).  A  close  and  effective 
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interface  among  these  systems  is  required  to  ensure  quality  products  are  acquired  for  the 
nation’s  armed  forces  (Peppe,  2002).  The  RGS  produced  information  for  decision¬ 
makers  on  the  projected  mission  needs  of  the  warfighter  and  was  a  bottom-up-driven 
process,  with  the  lowest  level  echelon  in  a  particular  functional  area  stating  its  desired 
needs  and  initiating  the  requirements  process. 

Figure  6  shows  the  initiation  of  the  RGS  from  both  the  bottom  echelon  and  top 
echelon  of  leadership.  The  top  portion  of  the  figure  shows  the  staffing  effort,  whereas  the 
bottom  portion  shows  the  movement  of  requirements  documents  for  definition,  validation 
and  approval. 
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Figure  6.  RGS  Requirements  Documents  Approval  Process:  Requirements  and  Acquisition 

Interface  Model  (From  CJCS,  2001,  p.  C-l,  D-l) 
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The  first  requirements  document  aided  decision-makers  in  the  RGS  by  translating 
the  identified  mission  needs  into  more  broad  and  generalized  operational  terms,  known  as 
the  mission  needs  statement  (MNS;  U.S.  Army  War  College,  2002).  MNSs  document  the 
needs  of  the  Army’s  operational  requirements  that  could  potentially  result  in  a  materiel 
solution  and,  eventually,  in  a  new  defense  acquisition  program.  Validation  of  the  MNS 
confirms  that  after  much  analysis,  a  non-materiel  solution  alone  cannot  satisfy  the  need, 
and  that  a  potential  “new  concept/system”  materiel  solution  should  be  considered  (Peppe, 
2002).  Subsequently,  the  needs  expressed  in  the  MNS  are  developed  into  requirements 
by  the  RGP  in  the  form  of  operational  requirements  documents  (ORDs)  or  capstone 
requirements  documents  (CRDs;  CJCS,  2001). 

Capstone  requirements  documents  are  excluded  from  the  scope  of  this  paper. 
However,  a  description  of  them  follows  to  provide  greater  understanding  of  requirements 
documents  and  the  RGP.  CRDs  outline  the  necessary  development  guidance  for  ORDs. 
The  guidance  provides  a  means  to  validate  performance-based  capabilities  for  a  specific 
mission  area.  Additionally,  this  mission  area  may  form  a  system  of  systems  (SoS)  or 
family  of  systems  (FoS).  CRDs  are  a  combination  of  two  or  more  MNSs  or  ORDs,  or  a 
combination  of  both  (U.S.  Army  War  College,  2002).  ORDs  define  the  MNS  and  (if 
applicable)  CRD  requirements  into  detailed,  refined  performance  capabilities  and 
characteristics  of  the  proposed  system.  ORDs  provide  the  specific  requirements  baseline 
for  the  Acquisition  Management  System  (AMS)  and  the  Planning,  Programming,  and 
Budgeting  System  (PPBS;  CJCS,  2001). 

Within  the  first  years  after  the  U.S.  deployment  into  Afghanistan,  the  RGS 
reached  its  culmination  and  was  no  longer  effective  for  both  the  DoD  and  the  Army.  The 
culmination  led  the  DoD  to  evolve  its  process  for  requirements  generation  from  the  RGS 
to  the  JCIDS. 

2.  Joint  Capabilities  Integration  Development  System  (2003-Present) 

In  2003,  Secretary  of  Defense  (SECDEF)  Donald  Rumsfeld  directed  the  DoD  to 
change  the  requirements  generation  process  (Figure  7). 
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The  Department  currently  is  pursuing  transformational  business  and 
planning  practices  such  as  adaptive  planning,  a  more  entrepreneurial, 
future-oriented  capabilities-based  resource  allocation  process,  accelerated 
acquisition  cycles  built  on  spiral  development,  out-put  based  management, 
and  a  reformed  analytic  support  agenda.  (DoD,  2003,  p.  1) 

SECDEF  Rumsfeld  identified  the  need  for  the  process  to  be  less  Service-centric, 
while  having  a  greater  Joint-centric  focus.  The  intent  of  the  JCIDS  concept  was  to 
eliminate  the  unnecessary  stove-piped  mentality  of  the  Services  and  write  requirements 
for  systems  that  could  be  used  across  all  Service.  This  note  may  be  seen  in  Figure  7. 


March  18,  2002  7:17  AM 

TO: 

Gen.  Pace 

CC: 

Paul  Wolfowitz 

Gen.  Myers 

Steve  Cambone 

FROM: 

Donald  Rumsfeld 

SUBJECT: 

Requirements  System 

As  Chairman  of  the  JROC,  please  think  through  what  we  all  need  to  do,  individually  or 
collectively,  to  get  the  requirements  system  fixed. 

It  is  pretty  clear  it  is  broken,  and  it  is  so  powerful  and  inexorable  that  it  invariably 
continues  to  require  things  that  ought  not  to  be  required,  and  does  not  require  things  that 

need  to  be  rc 

quired. 

Please  screw 

your  head  into  that,  and  let's  have  four  or  fix  e  of  us  meet  and  talk  about  it. 

Thanks. 

Figure  7.  Memo  From  Secretary  of  Defense  That  Began  JCIDS  (From  Force  Structure, 
Resources,  and  Assessments  Directorate  [JCS  J-8],  2006,  p.  5) 

The  DoD  immediately  responded  to  the  SECDEF  and  began  planning  to  quickly 
change  the  RGP.  Fifteen  months  after  receiving  the  SECDEF’s  email,  General  Peter 
Pace,  the  chairman  of  the  Joint  Chiefs  of  Staff,  answered  with  an  approved  solution.  By 
June  24,  2003,  the  JCIDS  replaced  RGS  and  CJCSI  3170.01C  (CJCS,  2003)  replaces 
CJCSI  3170.01B  (CJCS,  2001)  as  the  new  doctrine.  The  primary  goal  of  the  JCIDS  is  to 
provide  the  Joint  Force  with  the  necessary  capabilities  required  to  operate  in  full- 
spectrum  operations.  The  JCIDS  has  three  founding  principles: 

1.  Description  of  needs  by  capabilities  instead  of  systems, 
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2.  Emphasis  on  needs  at  the  joint  level  instead  of  at  the  level  of 
separated  branches  [of  Service],  and 

3.  One  single  general  or  flag  officer  to  manage  the  separate  DoD 
functional  portfolios.  (CJCS,  2003) 

The  evolutionary  change  from  the  RGS  to  JCIDS  also  changed  the  range  of 
considerations  of  non-materiel  solutions  from  DTLOMS  (doctrine,  training,  leader 
development,  organization,  materiel,  and  soldier)  to  DOTMLPF  (doctrine,  organization, 
training,  materiel,  leadership  and  education,  personnel,  and  facilities).  Essentially,  this 
modification  changed  leader  development  to  leadership  and  education ,  changed  soldier 
to  personnel ,  and  added  facilities.  Materiel  solutions  would  be  pursued  if  a  non-materiel 
solution  could  not  be  identified  through  the  initial  DOTMLPF  analysis.  Four  major  steps 
must  occur  in  the  analysis  prior  to  the  development  of  a  materiel  solution.  The  following 
list  outlines  the  four  steps  found  in  the  Defense  Acquisition  University  class 
“Functionality  of  the  JCIDS  Process”  (DAU,  2011): 

Step  1.  Top-down  analysis  based  on  the  National  Security  Strategy  (NSS), 
National  Defense  Strategy  (NDS),  and  the  Joint  Vision  2020; 

Step  2.  Integrated  architectures  of  multiple  operating  systems  analysis; 

Step  3.  Capability  gaps/shortcomings  and  associated  risk  analysis;  and 

Step  4.  Materiel  solution  recommendation  which  would  lead  to  the 
initiation  of  an  acquisition  program,  (p.  5) 

Figure  8  demonstrates  the  change  implemented  through  the  SECDEF’s  guidance. 
The  figure  shows  the  change  from  threat-based  to  capability-based  planning  and  the 
movement  from  a  bottom-up  approach  to  a  top-down  approach.  The  left  side  of  the 
figure  shows  the  RGS  process  while  the  right  side  shows  the  JCIDS  process. 
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Figure  8.  Threat  vs.  Capability-Based  Planning  (From  Willis,  2012,  slide  5) 


The  JCIDS  suspended  existing  RGS  documents,  which  consisted  of  the  MNS  and 
ORDs  with  the  ICD,  CDD,  and  CPD.  Figure  9  outlines  each  of  the  JCID  documents  and 
shows  how  each  document  is  intended  to  fit  into  the  JCIDS  process. 

The  flow  shown  in  Figure  9  occurs  from  enclosures  (boxes)  that  progress  into 
decision  points  (diamonds)  and  then  displays  appropriate  end  points  dependent  on  the 
path  followed.  The  ICD  is  found  at  the  Enclosure  B  step.  At  the  Enclosure  D  and  E 
steps  is  where  requirements  documents  (ICD,  CDD,  CPD,  JUONS)  enter  the  decision 
points.  The  subsequent  steps  are  based  on  the  decision  points.  A  “no”  decision  leads  to 
the  end  of  the  process  and  possible  reworking/correcting  of  documents.  However,  a 
“yes”  decision  moves  the  requirements  documents  into  the  deliberate  acquisition  process. 
This  process  may  be  better  understood  by  viewing  the  flow  lines  Figure  9. 
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Figure  9.  JCIDS  Requirements  Documents  Approval  Process 

(From  Joint  Requirements  Oversight  Council  [JROC],  2012b,  p.  2) 
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Since  2003,  the  JCIDS  process  has  been  updated  six  times  from  version  C  through 
version  H,  which  was  published  in  January  2012  (CJCS,  2012).  We  now  discuss  the 
details  for  each  of  the  specific  documents,  after  going  through  an  overview  for  the 
different  materiel  requirement  processes. 

C.  REQUIREMENTS  GENERATIONS  SYSTEM  (RGS)  MATERIEL 
REQUIREMENTS  DOCUMENTS  (MRD) — ( 1999- JUNE  2003) 

The  RGS  provides  information  for  decision  making  stakeholders  to  better 
understand  the  warfighter’s  mission  needs.  The  acquisition  process  begins  once  the 
milestone  decision  authority  (MDA)  decides  whether  or  not  the  need  will  be  met  with  a 
material  solution.  This  is  based  on  the  materiel  development  decision  that  identifies  that 
the  operational  capability  cannot  be  met  a  non-material  solution.  As  per  CJCSI  3170.01B 
(CJCS,  2001),  requirements  are  defined  as  mission  needs:  “A  deficiency  in  current 
capabilities  or  an  opportunity  to  provide  new  capabilities  (or  enhance  existing 
capabilities)  through  the  use  of  new  technologies.  They  are  expressed  in  broad 
operational  terms  by  the  DOD  components”  (p.  84).  The  three  major  requirements 
documents  that  were  used  to  fulfill  the  U.S.  Army’s  RGS  from  the  identified  need  to 
LRIP  are  the  mission  needs  statement  (MNS),  the  operational  requirements  document 
(ORD)-Initial,  and  the  ORD-Revised.  An  additional  capstone  requirements  document 
(CRD)  was  only  needed  as  required.  The  Global  Information  Grid  (GIG),  which  was 
approved  in  JROCM  134-01,  dated  August  30,  2001  (U.S.  Joint  Forces  Command,  2001), 
is  an  example  of  a  requirement  that  needed  a  CRD. 

The  concept  of  a  “Global  Information  Grid”  (GIG)  was  born  out  of 
concerns  regarding  interoperability  and  end-to-end  integration  of 
automated  information  systems.  Issues  such  as  streamlined  management 
and  the  improvement  of  information  infrastructure  investment  have  also 
contributed  to  the  heightened  interest  in  a  GIG.  However,  the  real  demand 
for  a  GIG  has  been  driven  by  the  requirement  for  information  superiority 
and  decision  superiority  to  achieve  full  spectrum  dominance,  as  expressed 
in  Joint  Vision  2020  (JV  2020).  JV  2020  also  highlights  the  importance  of 
a  network-centric  warfare  (NCW)  environment,  enabled  by  the  GIG  by 
means  of  dramatically  improved  information  sharing  through  the  robust 
networking  of  warfighting  forces.  (U.S.  Joint  Forces  Command,  2001,  p. 

2) 
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CRDs  were  a  means  to  combine  requirements  with  multi-systems  functions. 
Figure  10  depicts  the  necessary  requirements  documents  and  the  interface  with  the 
acquisition  system. 


Figure  10.  Requirements  and  Acquisition  Interface  Model  (From  CJCS,  2001,  p.  A-2) 


1.  Mission  Needs  Statement 

The  initial  requirements  document  in  the  Army’s  RGS  is  a  mission  needs 
statement  (MNS).  The  MNS  is  a  non-system-specific  document  that  states  an  operational 
capability  need(s).  By  this,  it  is  not  directed  for  a  specific  desired  system.  The  MNS 
identifies  a  capability  in  broad  operational  terms.  The  MNS  describes  the  warfighters 
operational  requirements  and  constraints  that  must  be  DOTMLP  analyzed,  and  may  result 
in  a  materiel  or  non-materiel  solution.  The  MNS  is  developed  by  four  distinct  phases:  (1) 
definition,  (2)  documentation,  (3)  validation,  and  (4)  approval  (CJCS,  2001). 

The  MNS  may  be  initiated  by  any  of  the  unified  commands,  military  departments, 
Office  of  the  Secretary  of  Defense  (OSD),  or  the  Joint  Staff.  However,  the  Combat 
Developer  (CBTDEV;  see  Combat  Developers/Capability  Developers  in  the  stakeholder 
section)  within  the  U.S.  Army  Training  and  Doctrine  Command  (TRADOC)  produces  the 
MNS.  The  MNS  outlines  a  list  of  operational  capabilities,  but  does  not  identify  a  specific 
materiel  solution  or  system.  A  warfighting  MNS  is  approved  by  the  chief  of  staff  of  the 
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Army.  A  CBTDEV-led  integrated  concept  team  (ICT,  see  Integrated  Teams  in  the 
stakeholder  section)  evaluates  the  capabilities  of  the  MNS.  This  ICT  identifies  the  strategy 
to  test  and  evaluate  a  system  of  materiel  solutions  that  attempts  to  answer  the  MNS. 

The  Unified  Commands,  the  military  departments,  OSD,  or  the  Joint  Staff  identify 
mission  needs.  The  Army  Requirements  Oversight  Council  (AROC),  prior  to  making  a 
recommendation  to  the  chief  of  staff  of  the  Army,  will  review  all  Joint/other  Service 
requirements.  The  chief  of  staff  of  the  Army  approves  all  MNSs  outlining  the 
warfighters’  needs. 

As  per  CJCSI  3170.01B:  Appendix  A  to  Enclosure  C,  dated  April  15,  2001 
(CJCS,  2001,  p.  C-A-l),  the  MNS  format  consists  of  the  following  parts: 

Part  1.  Defense  Planning  Guidance  Element 

Part  2.  Mission  and  Threat  Analysis 

Part  3.  Non-Materiel  Alternatives 

Part  4.  Potential  Materiel  Alternatives 

Part  5.  Constraints 

Part  6.  Joint  Potential  Designator 

2.  Operational  Requirements  Document 

The  operational  requirements  document  (ORD)  follows  the  MNS.  Prior  to  entry 
into  MS  B,  the  ORD  is  written  to  answer  the  MNS.  The  ORD  is  a  document  that  outlines 
the  performance  and  operational  boundaries  as  a  result  of  the  proposed  solution  for  an 
MNS.  The  CBTDEV/training  developer  (TNGDEV,  see  Combat  Developers/Capability 
Developers  in  the  stakeholder  section)  defines  the  objective  requirement  parameters.  The 
CBTDEV/TNGDEV  identifies  the  significant  operational  capability.  The  ORD-Initial 
must  contain  the  bottom-line  thresholds  that  the  capability  must  meet  through  KPPs. 

The  Headquarters,  Department  of  the  Army  (HQDA)  must  approve  all  ORDs 
before  a  program  is  approved.  Acquisition  programs  must  also  receive  HQDA  approval 
for  all  non-developmental  items,  commercial  items,  or  items  with  mature  technology. 
The  Joint  chief  of  staff  or  other  Service-specific  (JROC  approved)  leadership  may  only 
approve  acquisition  category  (AC AT)  ID-level  programs.  The  chief  of  staff  of  the  Army 
may  approve  all  Army-specific  programs  at  the  ACAT  IC  level. 
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The  ORD-Revised  later  redefines  the  KPP  as  well  as  the  objective  requirements 
for  a  materiel  solution.  ORDs  are  revised  prior  to  MS  C  and  are  required  to  receive 
approval  to  enter  MS  C.  Refinement  to  ORDs  occurs  after  MS  B  but  prior  to  MS  C  if 
there  are  any  changes  in  the  mission  needs. 

As  per  CJCSI  3170.01B:  Appendix  A  to  Enclosure  E,  dated  April  15,  2001, 

(CJCS,  2001,  p.  E-A-l)  the  ORD  format  consists  of  the  following  parts: 

Part  1.  General  Description  of  Operational  Capability 
Part  2.  Threat 

Part  3.  Shortcomings  of  Existing  Systems  and  C4ISR  Architectures 
Part  4.  Capabilities  Required 

Part  4. a.  System  Performance 

Part  4.b.  Information  Exchange  Requirements 

Part  4.c.  Logistics  and  Readiness 

Part  4.d.  Environmental,  Safety  and  Occupational  Health  (ESOH)  and 
Other  System  Characteristics 
Part  5.  Program  Support 

Part  5. a.  Maintenance  Planning 
Part  5.b.  Support  Equipment 

Part  5.c.  C4I/Standardization,  Interoperability,  and  Commonality 
Part  5.d.  Computer  Resources 
Part  5.e.  Human  Systems  Integration 
Part  5.f.  Other  Logistics  and  Facilities  Considerations 
Part  5.g.  Transportation  and  Basing 
Part  5.h.  Geospatial  Information  and  Services 
Part  5.i.  Natural  Environmental  Support 
Part  6.  Force  Structure 
Part  7.  Schedule 
Part  8.  Program  Affordability 

3.  Capstone  Requirements  Documents 

We  do  not  analyze  the  capstone  requirements  document  in  our  study.  However, 
understanding  the  CRD  is  necessary  for  the  overall  understanding  of  the  purpose  of 
requirements  documents.  CRDs  are  the  combination  of  more  than  one  MSN,  ORD,  or 
program  developed  as  a  family-of-systems  (FoS)  or  systems-of-systems  (SoS).  The  CRD 
links  MSNs  or  programs  into  one  synchronized  ORD  for  future  production  of  a  materiel 
solution.  Nonetheless,  CRDs  are  capabilities-based  requirements  that  combine 
requirements  documents  and  provide  a  means  to  merge  the  framework  of  multiple 
operational  initiatives  and  create  the  standards  for  the  development  of  materiel  solutions. 
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CRDs  are  the  overarching  requirements  documents  that  tie  multiple  needs  together  in 
order  to  meet  core  capabilities,  such  as  a  vehicle  requiring  a  specific  level  of 
survivability,  which  also  possesses  communication,  protection,  transportability,  power, 
and  maneuverability  capabilities  to  meet  a  need. 

CRDs  are  approved  by  HQDA  unless  they  are  ACAT  ID,  Joint,  or  other  Service- 
specific  (JROC  approved).  As  per  CJCSI  3170.01B:  Appendix  A  to  Enclosure  D,  dated 
April  15,  2001  (CJCS,  2001,  p.  D-A-l),  the  CRD  format  consists  of  the  following  parts: 

Part  1.  General  Description  of  Operational  Capability 

Part  2.  Threat 

Part  3.  Shortcomings  of  Existing  Systems  and  C4ISR  Architectures 

Part  4.  Capabilities  Required 

D.  JCIDS  MATERIEL  CAPABILITIES  DOCUMENTS  (MCD)— (POST  JUNE 

2003-PRESENT) 

In  2003,  the  Joint  Capabilities  Integration  and  Development  System  (JCIDS) 
replaced  the  RGS.  There  were  some  very  noteworthy  changes  that  took  place  outside  of 
merely  the  processes  and  documentation.  Concepts  and  terminology  were  also  changed. 
The  Materiel  Capabilities  Document  replaced  the  term  Materiel  Requirements  Document. 
Doctrine,  organization,  training,  materiel,  leadership  and  education,  personnel,  and 
facilities  (DOTMLPF)  replaced  DTLOMS.  “Mission  Needs,”  a  term  commonly  used  in 
CJCSI  3170.01B,  was  no  longer  a  term  in  CJCSI  3170.01C;  and  the  term  “Capability 
Gaps”  was  added.  Capability  gaps  are  “those  synergistic  resources  (DOTMLPF)  that  are 
unavailable  but  potentially  attainable  to  the  operational  user  for  effective  task  execution” 
(CJCS,  2003,  p.  GL-4).  By  CJCSI  3170.70H  (January  10,  2012),  capability  gaps  had 
evolved  into  the  following  definition:  “the  inability  to  execute  a  specified  course  of 
action.  The  gap  may  be  the  result  of  no  existing  capability,  lack  of  proficiency  or 
sufficiency  in  an  existing  capability  solution,  or  the  need  to  replace  an  existing  capability 
solution  to  prevent  a  future  gap”  (CJCS,  2012,  p.  31).  In  addition,  DOTMLPF  was 
replaced  by  DOTmLPF-P  (doctrine,  organization,  training,  materiel,  leadership,  policy 
and  education,  personnel,  facilities,  and  policy). 

Part  of  our  analysis  has  been  to  understand  why  CJCIS  3170.01  has  undergone  so 
many  evolutionary  changes.  This  is  consistent  with  the  concept  of  the  evolutionary 
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changes  to  the  RGP.  In  fewer  than  nine  years,  the  JCIDS  has  had  to  evolve  and  adapt  to 
the  changing  environment  of  the  GWOT.  Within  this  time  period,  the  DoD  has  adapted 
and  evolved  the  JCIDS  process  to  improve  efficiency  or  effectiveness  and  continues  to 
reevaluate  its  overall  process.  This  has  caused  the  JCIDS  process  to  undergo  six 
revisions  from  CJCSI  3170.01C  (CJCS,  2003)  through  CJCSI  3170.01H  (CJCS,  2012). 
Table  2  shows  the  length  of  time  between  each  change.  However,  this  evolutionary 
change  may  have  been  necessary  because  of  the  revolutionary  change  experienced  from 
moving  from  RGS  to  JCIDS.  Regardless,  a  revolutionary  change  for  JCIDS  has  not  been 
planned  or  executed  but  evolutionary  changes  to  the  process  have  been  redundantly 
implemented.  This  is  not  so  much  a  fault  of  the  DoD,  but  a  necessary  evil  of  the 
situation.  We  have  analyzed  whether  a  recurring  evolution  will  be  efficient  and  effective 
for  JCIDS  in  the  future.  A  revolutionary  change  to  JCIDS  may  be  necessary  if  the 
process  is  no  longer  effective  and  efficient,  like  its  predecessor,  the  RGS.  Plus,  another 
consideration  for  implementing  changes  is  if  materiel  solutions  are  not  meeting 
warfighters’  expectations  in  a  timely  manner. 


Table  2.  JCIDS  Amendments  and  Number  of  Months  Amendment  Was  Valid 


Publication 

Date  of  Publication 

Number  of  Months  Until 
Changed 

CJCSI  3170.01C 

June  24,  2003 

Approximately  nine  Months 

CJCSI  3170.01D 

March  14,  2004 

Approximately  nine  Months 

CJCSI  3170.01E 

May  11,  2005 

Approximately  11  Months 

CJCSI  3170.01F 

May  1,  2007 

Approximately  24  Months 

CJCSI  3170.01G 

March  1,  2009 

Approximately  22  Months 

CJCSI  3 170.0 1H 

January  10,  2012 

Ongoing 

Each  change  brought  a  new  publication  or  update  to  the  existing  CJCSI  for  the 
RGP.  However,  the  one  constant  that  remained  amongst  each  of  the  changes  was 
documents  and  their  timing  within  the  JCIDS.  Figure  11  shows  the  alignment  of  the 
different  materiel  requirements  documents  (ICD,CDD,CPD),  the  associated 
review/approval  authority  (triangles),  and  the  MS  review  boards  for  entering  into  the 
specific  MS  phase  of  the  RGP  (MS-A,  MS-B,  MS-C).  The  flow  of  the  figures 
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demonstrates  the  movement  and  use  of  documents  as  an  acquisition  program  approaches  its 
MS  and  then  transitions  to  the  next  phase  within  its  timeline.  An  example  of  this  is  moving 
from  MS  A  to  MS  B.  The  acquisition  program  exits  MS  A  with  the  appropriate  approval, 
transitions  from  using  the  ICD  to  using  the  CDD  at  MS  B,  as  depicted  in  the  below. 


DoD  Strategic  Guidance 


Family  of  Joint  Future  Concepts 
Concepts  of  Operations 
Integrated  Architectures 


ICO  -  Imbal  Capacities  Document 
CDD  -  Capability  Development  Document 
CPD  *  Capability  Production  Document 
AoA  -  Analysis  of  Alternatives 


CDO 


X 


i 


JROC 


CPD - 


•  IOC 


A  A 


DAB/ 

DSAB/ 

ITAB 


JROC 


DAB/ 

DSAB/ 

ITAB 


JROC  -  Joint  Requirements  Oversight  Counol 
DAB  -  Defense  Acquisition  Board 
DSAB  -  Defense  Space  Acquisition  Board 
ITAB  -  Information  Technology  Acquisition  Board 


Figure  11.  Flow  of  Materiel  Capabilities  Documents  in  the  JCIDS  Process 

(FromDAU,  2011,  p.  2) 


1.  Initial  Capabilities  Document 

The  initial  capabilities  document  (ICD)  replaced  the  MNS.  This  document  is 
required  at  the  decision  point  prior  to  moving  into  the  materiel  solution  analysis  phase. 
The  purpose  of  the  ICD  is  to  document  the  possible  non-materiel  or  materiel  solution  or  a 
mixture  of  both  to  satisfy  an  identified  capability  gap.  The  ICD  is  similar  to  its 
predecessor,  the  MNS,  because  it  is  not  system  specific.  The  ICD  only  describes  the 
capability  needed  or  a  capability  gap.  However,  if  a  materiel  solution  is  approved  by  the 
MDA  then  an  analysis  of  alternatives  (AoA)  might  be  required.  The  AoA  would  be  used 
to  support  an  MS  A  decision  (Headquarters,  Department  of  the  Army  [HQDA],  2009). 

In  CJCSI  3170.01C  (CJCS,  2003),  ICDs  were  defined  as  follows: 

Documents  the  need  for  a  materiel  approach  to  a  specific  capability  gap 

derived  from  an  initial  analysis  of  materiel  approaches  executed  by  the 
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operational  user  and,  as  required,  an  independent  analysis  of  materiel 
alternatives.  It  defines  the  capability  gap  in  terms  of  the  functional  area, 
the  relevant  range  of  military  operations,  desired  effects  and  time.  The 
ICD  summarizes  the  results  of  the  DOTMLPF  analysis  and  describes  why 
non-materiel  changes  alone  have  been  judged  inadequate  in  fully 
providing  the  capability,  (p.  GL-6) 

In  CJCSI  3170.01H  (CJCS,  2012),  ICDs  is  redefined  as  follows: 

Summarizes  a  CBA  and  justifies  the  requirement  for  a  materiel  or  non¬ 
materiel  approach,  or  an  approach  that  is  a  combination  of  materiel  and 
non-materiel,  to  satisfy  specific  capability  gap(s).  It  identifies  required 
capabilities  and  defines  the  capability  gap(s)  in  terms  of  the  functional 
area,  the  relevant  range  of  military  operations,  desired  effects,  time  and 
doctrine,  organization,  training,  materiel,  leadership  and  education, 
personnel,  and  facilities  (DOTMLPF)  and  policy  implications  and 
constraints.  The  ICD  summarizes  the  results  of  the  DOTMLPF  and  policy 
analysis  and  the  DOTMLPF  approaches  (materiel  and  non-materiel)  that 
may  deliver  the  required  capability.  The  outcome  of  an  ICD  could  be  one 
or  more  joint  DCRs  or  recommendations  to  pursue  materiel  solutions,  (p. 

GL-5) 

Initially  in  2003,  CJCSI  3170.01C  outlined  that  the  documents  were  focused  on  a 
materiel  solution  to  meet  a  capability  gap.  This  would  often  result  in  the  creation  of  new 
programs.  The  intent  evolved  over  nine  years  as  CJCSI  3170.01  was  modified  through 
versions  C,  D,  E,  F,  G,  and  H.  CJCSI  3170.01H  outlined  a  more  revised  approach  for  the 
ICD.  The  definition  for  the  most  recent  ICD  still  includes  a  possible  materiel  solution, 
but  also  includes  non-materiel  solution,  changes  to  policy,  changes  to  DOTMLPF,  or 
variations  of  combining  these  to  fill  a  capability  gap.  This  shift  in  intent  for  changes  to 
the  purpose  of  the  ICD  is  a  result  of  changes  in  the  DoD’s  budget,  organizations, 
operations,  and  considerations  of  the  future  state  of  the  DoD  in  downsizing. 

The  ICD  provides  an  overview  of  the  capability-based  assessment  where  a  non¬ 
materiel  solution  has  been  identified  not  to  exist  or  to  be  inadequate  to  meet  the  needs  of 
a  capability  gap.  The  ICD  must  consider  DOTMLPF  non-materiel  solutions.  The  ICD 
also  proposes  a  materiel  approach  and  must  justify  why  the  proposed  materiel  approach 
best  meets  the  needs  to  solve  the  required  capability  gap.  Once  the  document  has  been 
written  and  approved  it  can  lead  to  one  or  more  DOTMLPF  Integrated  Capabilities 
Recommendation  (DICR),  DCR,  CDD,  or  CPD  (HQDA,  2009). 
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As  per  the  JCIDS  Manual,  (CJCS,  2012,  p.  B-l),  the  ICD  format  consists  of  the 
following  parts: 

Part  1.  Length  (Part  3  and  Appendix  A  may  not  exceed  10  pages) 

Part  2.  Cover  Page 

Part  2. a.  Classification 

Part  2.b.  Title.  The  title  must  start  with  the  phrase  “Initial  Capability 
Document  for...” 

Part  2.c.  Sponsoring  organization 

Part  2.d.  Date  submitted  by  the  sponsoring  organization 

Part  2.e.  Points  of  contact  (primary  and  secondary) 

Part  2.f.  Proposed  validation  authority 
Part  2.g.  Proposed  milestone  decision  authority 
Part  2.h.  Proposed  joint  staff  designator 
Part  3.  Executive  Summary  (Seven  primary  sections) 

Section  1.  Contingency  operations  (CONOP)  summary 

Section  2.  Joint  Capability  Area  (JCA)  and  identified  Integrated  Security 

Construct  (ISC) 

Section  3.  Capability  requirements 
Section  4.  Capability  gaps  and  overlaps/redundancies 
Section  5.  Threat  and  operational  environment 
Section  6.  Assessment  of  non-materiel  approaches 
Section  7.  Final  recommendation 
Appendix  A.  Architecture  data 
Appendix  B.  References 
Appendix  C.  Acronym  List 
Appendix  D.  Glossary 

2.  Capability  Development  Document 

This  document  replaced  the  ORD-initial.  The  capability  development  document 
(CDD)  is  developed  during  MS  A  and  is  required  prior  to  the  MDA’s  decision  for 
approval  for  moving  into  MS  B.  The  ICD  develops  and  guides  the  CDD.  A  CDD  is  not 
submitted  until  the  AoA  is  complete,  unless  there  is  an  approved  justification  regarding 
why  an  AoA  is  not  required.  The  CDD  is  the  document  that  allows  the  sponsor(s)  to 
further  refine  the  required  capabilities.  These  capabilities  are  expressed  as  performance 
attributes  that  contain  threshold  and  objective  values  (HQDA,  2009).  The  sponsor 
enhances  the  capability  required  by  defining  the  KPPs,  key  system  attribute  (KSA),  or 
other  descriptors.  CDDs  must  be  updated  with  any  changes  to  the  KPPs.  Additionally, 
the  KPPs  contained  in  the  CDD  are  taken  verbatim  into  the  acquisition  program  baseline 

(APB)  and  are  validated  by  the  JROC  (HQDA,  2009). 
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Since  the  CDD  serves  as  the  next  main  step  for  MCDs,  there  is  no  surprise  that  it 
contains  information  necessary  for  the  development  of  the  proposed  program.  Plus,  it 
routinely  follows  an  incremental  acquisition  strategy.  To  aid  in  this  process,  “the  CDD 
outlines  an  affordable  increment  of  militarily  useful,  logistically  supportable,  and  technically 
achievable  or  mature  capability”  (HQDA,  2009,  p.  20).  In  addition  to  this,  the  CDD  can  be 
used  for  multiple  increments  if  sufficient  performance  attributes  are  properly  defined.  One  or 
more  CDDs  may  be  developed  to  provide  support  for  multiple  or  complex  capability  gaps 
that  are  identified  and  explained  within  a  single  ICD  (HQDA,  2009). 

As  per  the  JCIDS  Manual,  Enclosure  B  (CJCS,  2012,  pp.  B-29-B-37),  the  CDD 

format  consists  of  the  following  parts: 

Part  1.  Length.  (Part  3  and  Appendix  A  may  not  exceed  45  pages) 

Part  2.  Cover  Page. 

Part  2. a.  Classification 

Part  2.b.  Title.  The  title  must  start  with  the  phrase  “Capability 
Development  Document  for. . .” 

Part  2.c.  Sponsoring  organization,  and  signature  authority  who  authorized 
the  submittal  into  JCIDS.  New  CDDs,  and  modifications  to 
previously  validated  CDDs,  must  be  endorsed  by  the  Service, 
CCMD,  or  other  DoD  Component  J8  equivalent  or  higher 
Part  2.d. 

(d)  Date  submitted  by  the  sponsoring  organization. 

(e)  Primary  and  secondary  POCs  for  the  document  sponsor. 

Include  name,  title/rank,  phone,  and  both  Non-Classified 
Internet  Protocol  (IP)  Router  Network  (NIPRNET)  and 
Secure  IP  Router  Network  (SIPRNET)  email  addresses. 
POCs  must  have  completed  the  appropriate  level  of  RMCT 
in  accordance  with  Enclosure  H. 

(f)  Proposed  validation  authority 

(g)  Proposed  MDA 

(h)  Proposed  JSD 

Proposed  Acquisition  Category  (ACAT) 

(3)  Executive  Summary.  An  executive  summary,  not  to  exceed  one 
page,  shall  follow  the  cover  page  and  precede  the 
body  of  the  CDD. 

c.  Section  Descriptions.  The  CDD  shall  have  the  following  16 
sections,  followed  by  four  appendices. 

(1)  Capability  Discussion 

(a)  Discuss  the  operating  environment  of  the  system. 

(b)  If  the  CDD  is  part  of  an  FoS  or  SoS  solution,  identify 

the  source  ICD  and  related  CDDs  and  CPDs. 
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(2)  Analysis  Summary 

(3)  CONOPS  Summary 

(4)  Threat  Summary 

(a)  Summarize  the  projected  threat  environment  and  the 

specific  threat  capabilities  to  be  countered  to  ensure 
the  capability  gap  can  be  mitigated. 

(b)  Programs  designated  as  ACAT  I/ID  (or  potential  ACAT 

I/ID)  must  incorporate  DIA-validated  threat 
references. 

(c)  During  staffing,  documents  with  JSDs  of  JROC  Interest, 

JCB  Interest,  and  Joint  Integration  will  be  subject  to 
Defense  Warning  Office  (DWO)  threat  validation  in 
accordance  with  reference  pp. 

(5)  Program  Summary 

(6)  Development  KPPs,  KSAs,  and  additional  performance 

attributes 

(a)  Sponsors  must  consider  the  six  “required”  KPPs 

detailed  in  Appendix  A  to  this  Enclosure. 

(b)  Sponsors  should  avoid  over  specification  of 

KPPs/KSAs,  or  inclusion  of  technical  specifications 
as  KPPs/KSAs,  unless  essential  to  addressing  a 
specific  capability  gap. 

(c)  Provide  a  description  of  each  attribute  and  list  each 

attribute  in  a  separate  numbered  subparagraph. 

(d)  Present  each  attribute  in  output-oriented,  measurable, 

and  testable  terms. 

(e)  Provide  tables  summarizing  specified  KPPs,  KSAs,  and 

additional  performance  attributes  in 
threshold/objective  format,  as  illustrated  in  Tables 
B-6  through  B-8. 

(7)  SoS  Synchronization.  In  SoS  capability  solutions,  the  CDD 

Sponsor  is  responsible  for  ensuring  that  related  capability 
solutions,  identified  in  other  CDDs  and  CPDs,  remain 
compatible  and  that  the  development  is  synchronized. 

(a)  Discuss  the  relationship  of  the  system  described  in  this 

CDD  to  other  systems  contributing  to  satisfying  the 
capability  requirements. 

(b)  Provide  a  table  that  briefly  describes  the  contribution 

this  CDD  makes  to  the  fulfillment  of  capability 
requirements  and  closing  of  capability  gaps 
described  in  the  applicable  ICDs,  and  the 
relationships  to  other  CDDs  and  CPDs  that  also 
support  these  capability  requirements,  as  illustrated 
in  Table  B-9. 

(8)  Spectrum  Requirements 
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(9)  Intelligence  Supportability 

(a)  Identify,  as  specifically  as  possible,  all  projected  need 

for  intelligence  support  throughout  the  expected 
acquisition  life  cycle  in  accordance  with  reference 

pp. 

(b)  During  staffing,  documents  with  JSDs  of  JROC  Interest, 

JCB  Interest,  and  Joint  Integration  will  be  subject  to 
Joint  Staff  J-2  intelligence  certification  in 
accordance  with  reference  pp. 

(10)  Weapon  Safety  Assurance.  In  accordance  with  reference  tt,  all 

munitions  capable  of  being  handled,  transported,  used,  or 
stored  by  any  Service  in  joint  warfighting  environments  are 
considered  to  be  joint  weapons  and  require  a  joint  weapons 
safety  review  in  accordance  with  Appendix  A  to  Enclosure 
D  of  this  Manual  and  references  tt  through  vv. 

(a)  System  Safety 

(b)  Insensitive  Munitions 

(c)  Fuze  Safety 

(d)  Explosive  Ordnance  Disposal 

(e)  Demilitarization/Disposal 

(f)  Laser  Safety 

(11)  Technology  Readiness  Assessment 

(12)  Assets  Necessary  to  Achieve  IOC 

(13)  IOC  and  FOC  Schedule  Definitions 

(14)  DOTmLPF-P  Considerations 

(a)  Discuss  any  additional  DOTmLPF-P  implications 

associated  with  fielding  the  system,  to  include  those 
approaches  that  would  impact  CONOPS  or  plans 
within  a  CCMD  Area  of  Responsibility  (AOR). 

(b)  Highlight  the  status  (timing  and  funding)  of  the  other 

DOTmLPF-P  considerations. 

(c)  Describe,  at  an  appropriate  level  of  detail,  the  key 

logistics  criteria,  such  as  system  reliability, 
maintainability,  transportability,  and  supportability 
that  will  help  minimize  the  system’s  logistics 
footprint,  enhance  mobility,  and  reduce  the  total 
ownership  cost. 

(d)  Detail  any  basing  needs  (forward  and  main  operating 

bases,  institutional  training  base,  and  depot 
requirements). 

(e)  Specify  facility;  shelter;  supporting  infrastructure;  and 

Environment,  Safety,  and  Occupational  Health 
(ESOH)  asset  requirements,  and  the  associated 
costs,  availability,  and  acquisition  MS  schedule(s) 
related  to  supporting  the  system. 
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(f)  Describe  how  the  systems  will  be  moved  either  to  or 
within  the  theater,  and  identify  any  lift  constraints. 

(15)  Other  System  Attributes 

(a)  Anti-tamper,  embedded  instrumentation,  electronic 

attack  (EA),  and  wartime  reserve  mode  (WARM) 
requirements. 

(b)  Human  Systems  Integration  (HSI)  considerations  that 

have  a  major  impact  on  system  effectiveness  and 
suitability. 

(c)  Natural  environmental  factors  (climatic  design  type, 

terrain,  meteorological  and  oceanographic  factors, 
impacts  and  effects). 

(d)  Expected  level  of  capability  provided  in  various  mission 

environments,  if  degraded  relative  to  KPPs,  KSAs, 
and  additional  performance  attributes  articulated  in 
Section  6  of  the  CDD. 

(e)  Physical  and  operational  security  needs. 

(f)  Weather,  oceanographic  and  astro-geophysical  support 

needs  throughout  the  program’s  expected  life  cycle, 
including  data  accuracy  and  forecast  needs. 

(g)  For  intelligence,  surveillance,  and  reconnaissance  (ISR) 

platforms,  issues  relating  to  information  security 
and  protection  standards. 

(h)  For  systems  that  may  be  used  in  combined  allied  and 

coalition  operations,  issues  relating  to  applicable 
U.S. -ratified  international  standardization 
agreements  which  will  be  incorporated  in  the 
derived  system  requirements,  in  accordance  with 
references  ggg  and  hhh. 

(i)  Whether  or  not  the  system  must  be  able  to  survive  and 

operate  through  chemical,  biological,  radiological, 
and  nuclear  (CBRN)  environments  in  accordance 
with  reference  iii. 

(16)  Program  Affordability.  Show  total  cost  as  shown  in  Table  B- 

10,  including  cost  by  FY  and  type  of  funding  based  upon 
threshold  levels  of  performance. 

d.  Appendices 

(1)  Appendix  A:  Net-Ready  KPP  (NR  KPP)  Architecture  Data 

(2)  Appendix  B:  References 

(3)  Appendix  C:  Acronym  Fist 

(4)  Appendix  D:  Glossary 
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3. 


Capability  Production  Document  (CPD) 


This  document  replaced  the  ORD-revised  just  prior  to  LRIP.  The  capability 
production  document  (CPD)  can  also  be  an  amended  version  of  the  CDD,  which  is  useful 
since  these  documents  have  a  similar  format  (HQDA,  2009).  “The  CPD  addresses  the 
production  elements  specific  to  a  single  increment  of  an  acquisition  program  resulting 
from  an  approved  CDD  or  mature  existing  technology”  (HQDA,  2009,  p.  20).  A  key 
difference  between  the  CDD  and  the  CPD  is  the  use  of  performance  attributes.  The  CPD 
transforms  the  performance  specification  threshold  and  objective  values  into  production 
threshold  and  objective  values  (HQDA,  2009).  Another  difference  between  the  two 
documents  is  that  a  CPD  is  required  for  any  acquisition  program  to  enter  into  production, 
whereas  the  CDD  is  needed  for  an  acquisition  program  that  still  needs  to  develop  mature 
technology  before  proceeding  into  production.  Additionally,  the  document  is  used  to 
move  beyond  MS  C,  enter  into  the  production  phase,  and  address  the  production  elements 
of  a  specific  increment  of  an  acquisition  program  (HQDA,  2009). 

As  per  the  JCIDS  Manual,  Enclosure  B,  dated  January  19,  2012  (CJCS,  2012,  pp.  B-41- 
B-49),  the  CPD  format  consists  of  the  following  parts: 

Part  1.  Length.  The  body  of  a  CPD — consisting  of  the  16  primary  sections  and 
Appendix  A — shall  be  no  more  than  40  pages  long. 

Part  2.  Cover  Page.  The  cover  page  of  a  CPD  shall  include  the  following 
information. 

Part  2. a.  Classification 

Part  2.b.  Title,  starting  with  the  phrase  “Capability  Production  Document 
for...” 

Part  2.c.  Sponsoring  organization,  and  signature  authority  who  authorized 
the  submittal  into  JCIDS.  New  CPDs,  and  modifications  to 
previously  validated  CPDs,  must  be  endorsed  by  the  Service, 
CCMD,  or  other  DoD  Component  J8  equivalent  or  higher. 

Part  2.d.  Date  submitted  by  the  sponsoring  organization 

Part  2.e.  Primary  and  secondary  POCs  for  the  document  sponsor 

Part  2.f.  Proposed  validation  authority 

Part  2.g.  Proposed  Milestone  Decision  Authority  (MDA) 

Part  2.h.  Proposed  Joint  Staffing  Designator  (JSD) 

Part  2.i.  Proposed  Acquisition  Category  (ACAT) 

Part  3.  Executive  Summary.  An  executive  summary,  not  to  exceed  one  page,  shall 
follow  the  cover  page  and  precede  the  body  of  the  CPD. 

Part  4.  The  CPD  shall  have  the  following  16  sections  followed  by  four 
appendices. 
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Part  4. a.  Capability  Discussion 

Part  4.a.l.  Discuss  the  operating  environment  of  the  system. 

Part  4. a. 2.  If  the  CPD  is  part  of  an  FoS  or  SoS  solution,  identify  the 
source  ICD  and  related  CDDs  and  CPDs. 

Part  4.b.  Analysis  Summary 
Part  4.c.  CONOPS  Summary 
Part  4.d.  Threat  Summary 

Part  4.d.l.  Summarize  the  projected  threat  environment  and  the 

specific  threat  capabilities  to  be  countered  to  ensure  that  the 
capability  gap  can  be  mitigated 

Part  4.d.2.  Programs  designated  as  ACAT  FID  (or  potential  ACAT 
FID)  must  incorporate  DIA-validated  threat  references.  All 
other  programs  may  use  DoD  Component  intelligence 
center-approved  products  and  data. 

Part  4.d.3.  During  staffing,  documents  with  JSDs  of  JROC  Interest, 
JCB  Interest,  and  Joint  Integration  will  be  subject  to 
Defense  Warning  Office  (DWO)  threat  validation. 

Part  4.e.  Program  Summary 

Part  4.f.  Production  KPPs,  KSAs,  and  additional  performance  attributes 

Part  4.f.l.  Sponsors  must  consider  the  six  “required”  KPPs. 

Part  4.f.2.  As  in  the  CDD,  care  must  be  taken  to  stabilize  and  not 
over  specify  attributes  in  the  CPD.  Only  the  most 
significant  items  should  be  designated  as  performance 
attributes  with  threshold  and  objective  values. 

Part  4.0.  Provide  a  description  for  each  attribute  and  list  each 
attribute. 

Part  4.f.4.  Present  each  attribute  in  output-oriented,  measurable, 
and  testable  terms. 

Part  4.f.5.  Provide  tables  summarizing  specified  KPPs,  KSAs  and 
additional  performance  attributes  in  threshold/objective 
format. 

Part  4.g.  SoS  Synchronization 

Part  4.g.l.  Discuss  the  relationship  of  the  system  described  in  this 
CPD  to  other  systems  contributing  to  satisfying  the 
capability  requirements.  Discuss  any  overarching 
DOTmLPF-P  changes  needed  to  make  the  SoS  an  effective 
military  capability  solution. 

Part  4.g.2.  Provide  a  table  that  briefly  describes  the  contribution 
this  CPD  makes  to  the  fulfillment  of  capability 
requirements  and  closing  of  capability  gaps  described  in  the 
applicable  ICDs,  and  the  relationships  to  other  CDDs  and 
CPDs  that  also  support  these  capability  requirements. 

Part  4.h.  Spectrum  Requirements 
Part  4.i.  Intelligence  Supportability 
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Part  4.i.  1 .  Identify,  as  specifically  as  possible,  all  projected 
requirements  for  intelligence  support  throughout  the 
expected  acquisition  life  cycle  in  accordance  with  the 
format  and  content  prescribed. 

Part  4.i.2.  During  staffing,  documents  with  JSDs  of  JROC  Interest, 
JCB  Interest,  and  Joint  Integration  will  be  subject  to  Joint 
Staff  J-2  intelligence  certification. 

Part  4.j.  Weapon  Safety  Assurance.  The  CPD  will  address  the  following: 
Part  4.j.l.  System  Safety 
Part  4.j.2.  Insensitive  Munitions 
Part  4.j.3.  Fuze  Safety 
Part  4.j.4.  Explosive  Ordnance  Disposal 
Part  4.j.5.  Demilitarization/Disposal 
Part  4.j.6.  Laser  Safety 

Part  4.k.  Technology  and  Manufacturing  Readiness 

Part  4.1.  Assets  Required  to  Achieve  FOC.  Describe  the  types  and 
quantities  of  assets  required  to  attain  FOC. 

Part  4.m.  IOC  and  FOC  Schedule  Definitions 

Part  4.n.  Other  DOTmLPF-P  Considerations 

Part  4.n.l.  Discuss  any  additional  DOTmLPF-P  implications 
associated  with  fielding  the  system,  to  include  those 
approaches  that  would  impact  CONOPS  or  plans  within  a 
CCMD  AOR.  Describe  the  implications  for  all 
recommended  changes. 

Part  4.n.2.  Highlight  the  status  (timing  and  funding)  of  the  other 
DOTmLPF-P  considerations. 

Part  4.n.3.  Describe,  at  an  appropriate  level  of  detail,  the  key 

logistics  criteria,  such  as  system  reliability,  maintainability, 
transportability,  and  supportability  that  will  help  minimize 

the  system’s  logistics  footprint,  enhance  mobility,  and 
reduce  the  total  ownership  cost.  Also  discuss  energy 
demand  impacts,  including  fuel  and/or  electrical  power,  if 
applicable. 

Part  4.n.4.  Detail  any  basing  needs  (forward  and  main  operating 
bases,  institutional  training  base,  and  depot  requirements). 
Part  4.n.5.  Specify  facility,  shelter,  supporting  infrastructure,  and 
ESOH  asset  requirements,  and  the  associated  costs, 
availability,  and  acquisition  MS  schedule(s)  related  to 
supporting  the  system. 

Part  4.n.6.  Describe  how  the  system  will  be  moved  either  to  or 
within  the  theater.  Identify  any  lift  constraints. 

Part  4.o.  Other  System  Attributes.  Address  any  other  attributes  not 

previously  identified,  especially  those  that  tend  to  be  design,  cost, 
or  risk  drivers,  including  but  not  limited  to  the  following: 
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Part  4.0.1.  Anti-tamper,  embedded  instrumentation,  EA,  and 
WARM  requirements. 

Part  4.O.2.  HSI  considerations  that  have  a  major  impact  on  system 
effectiveness,  suitability,  and  affordability. 

Part  4.O.3.  Natural  environmental  factors  (climatic  design  type, 
terrain,  meteorological  and  oceanographic  factors,  and 
impacts  and  effects). 

Part  4.0.4.  Expected  level  of  capability  provided  in  various  mission 
environments,  if  degraded  relative  to  KPPs,  KSAs,  and 
additional  performance  attributes  articulated  in  Section  6  of 
the  CPD.  Include  applicable  safety  parameters,  such  as 
those  related  to  system,  nuclear,  explosive,  and  flight 
safety. 

Part  4.0.5.  Physical  and  operational  security  needs. 

Part  4.0.6.  Weather,  oceanographic  and  astro-geophysical  support 
needs  throughout  the  program’s  expected  life  cycle, 
including  data  accuracy  and  forecast  needs. 

Part  4.0.7.  For  ISR  platforms,  issues  relating  to  information 
protection  standards. 

Part  4.0.8.  For  systems  that  may  be  used  in  combined  allied  and 
coalition  operations,  issues  relating  to  the  potentially 
applicable  U.S. -ratified  international  standardization 
agreements.  Provide  an  initial  indication  of  which  ones  will 
be  incorporated  in  the  derived  system  requirements. 

Part  4.0.9.  Whether  or  not  the  system  must  be  able  to  survive  and 
operate  through  CBRN  environments. 

Part  4.p.  Program  Affordability 
Part  5.  Appendices 

(1)  Appendix  A.  Net-Ready  KPP  Architecture  Data 

(2)  Appendix  B.  References 

(3)  Appendix  C.  Acronym  List 

(4)  Appendix  D.  Glossary 

E.  STAKEHOLDERS 

Every  requirements  document  has  a  vast  network  of  personnel  who  have  specific 
responsibilities  associated  with  a  particular  document.  This  begins  at  conception  as  a 
document  comes  into  existence,  all  the  way  through  staffing  and  approval,  and  eventually 
onto  execution.  Knowing  the  stakeholders  involved  throughout  the  review  and  approval 
process  leads  to  an  understanding  of  the  efficiency  and  effectiveness  of  the  documents. 
Additionally,  this  provides  the  ability  to  analyze  what  changes  are  needed  to  aid  a 
specific  set  of  stakeholders  for  the  lifespan  of  the  document. 
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Determining  specific  stakeholders  first  requires  defining  the  term  “stakeholder.” 
In  addition,  the  term  “stakeholder”  is  commonly  used  in  conjunction  with  the  term 
“user.”  Generally,  the  term  “user”  in  the  DoD  refers  to  the  “warfighter.”  The  warfighters 
are  the  personnel  that  directly  use  the  product  produced  from  an  acquisition  program 
guided  by  requirements  documents  from  the  old  RGS  and  the  new  JCIDS  processes.  In 
this  paper,  the  tenn  “user”  applies  to  materiel  developer  and  the  acquisition  program 
office.  These  are  the  entities  that  use  the  requirements  documents  to  produce  a  material 
solution.  Whereas,  the  tenn  “stakeholder”  applies  to  the  multiple  entities,  person  or 
office,  that  have  roles  dealing  with  the  development  and  writing,  review  and  approval, 
and  ultimately  the  execution  of  a  requirements  document. 

Warfighters  are  both  the  stakeholders  and  users  in  the  RGP.  As  a  user,  they  are 
the  beginning  and  end  point  for  the  use  of  a  product  produced  from  the  acquisition 
process.  CJCSI  3170.01C  defines  user  and  user  representatives  as  follows: 

user  -  An  operational  command  or  agency  that  receives  or  will  receive 
benefit  from  the  acquired  system.  Combatant  commanders  and  their 
Service  Component  commands  are  the  users.  There  may  be  more  than  one 
user  for  a  system.  Because  the  Service  Component  commands  are  required 
to  organize,  equip  and  train  forces  for  the  combatant  commanders,  they 
are  seen  as  users  for  systems.  The  Chiefs  of  the  Services  and  heads  of 
other  DOD  Components  are  validation  and  approval  authorities  and  are 
not  viewed  as  users. 

user  representative  -  A  command  or  agency  that  has  been  formally 
designated  by  proper  authority  to  represent  single  or  multiple  users  in  the 
capabilities  and  acquisition  process.  The  Services  and  the  Service 
Components  of  the  combatant  commanders  are  normally  the  user 
representatives.  There  should  only  be  one  user  representative  for  a  system. 

(CJCS,  2012,  p.  GL-11) 

These  quotes  show  how  the  warfighter  is  viewed  as  the  overall  user  for  an  acquisition 
program.  However,  we  are  looking  at  the  warfighter  in  a  stakeholder  perspective.  As  a 
stakeholder,  they  initiate  the  acquisition  process  by  stating  and  identifying  a  need  for 
some  solution  to  an  existing  capability  gap  that  prevents  them  from  completing  their 
mission.  Warfighters  submit  their  request  for  a  desired  need  to  the  CMBTDEV, 
providing  the  first  requirement  to  the  RGP.  From  this  point  forward,  the  CMBTDEV 
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develops  and  writes  the  requirements  for  the  warfighter/combatant  commanders. 
Additionally,  field  commanders  submit  an  ONS/UONS  to  request  a  solution  for  a 
capability  gap  (HQDA,  2009). 

Stakeholders  involved  in  a  specific  requirements  document  can  be  identified. 
Stakeholders  are  those  entities  directly  associated  with  the  development,  staffing, 
approval,  and  execution  of  the  requirements  documents.  Many  stakeholders  have 
multiple  roles  within  requirements  documents.  In  the  following  sections,  all  stakeholders 
are  described  and  their  involvement  and  responsibilities  with  a  particular  requirement 
document  are  explained.  However,  the  order  of  presented  stakeholders  does  not  signify  a 
specific  priority  or  level  of  importance  for  the  stakeholders. 

In  2003,  a  revolutionary  change  was  identified  to  support  the  warfighters  involved 
in  the  GWOT.  “What’s  taking  place  in  the  conflict  [Afghanistan],  in  the  global  war  on 
terrorism,  and  the  distinctively  new  threats  we’re  facing,  [provides]  the  impetus  to 
transformation”  (Lucas,  Sanchez,  Thomas,  &  Ipekci,  2003,  pp.  1-2).  As  the  Army  and  the 
DoD  close  the  GWOT  in  Afghanistan,  a  change  may  be  required  to  support  future 
initiatives  of  the  National  Defense  Strategy  of  the  RGP.  The  future  RGP  must  undergo 
changes,  whether  these  changes  are  evolutionary  or  revolutionary,  to  adapt  to  this  future 
environment  and  must  consider  budget,  downsizing,  technology,  and  future  capability  gaps. 
The  greatest  questions  are  based  off  lessons  learned  from  the  past,  and  what  measures  are 
required  in  order  not  to  repeat  the  shortfalls  of  these  lessons  learned.  Ultimately,  the 
question  is  this:  Should  the  future  of  the  RGP  be  an  additional  fragmentary  order 
(FRAGO),  quick  revision/alteration  of  a  base  policy/plan/procedure,  of  JCIDS,  or  should 
the  U.S.  Army  write  a  new  operation  order  (OPORD),  policy/plan/procedure,  that  creates  a 
new  process  and  different  documents?  Stakeholders  were  integral  in  the  RGP’s 
evolutionary  changes  to  produce  both  efficient  and  effective  MCDs. 

1.  Integrated  Teams 

Various  types  of  teams  conduct  an  array  of  missions  throughout  the  RGP.  Each 
team  performs  functions  that  are  essential  to  the  efficiency  of  the  defense  acquisition 
system.  Functions  range  from  roles  that  are  directly  associated  with  requirements 
documents  to  roles  that  transform  requirements  into  useable  performance  specifications 
for  industry. 
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Integrated  concept  teams  (ICTs)  are  teams  of  personnel  that  have  specific  skill 
sets  within  their  discipline.  Personnel  serving  on  ICTs  include  program  managers, 
doctrine  writers,  combat  developers,  action  officers  from  branch  proponent  schools,  and 
representatives  from  the  Office  of  the  Secretary  of  Defense,  HQDA,  industry,  national 
laboratories,  and  potential  users.  Personnel  serving  on  ICTs  serve  to  bring  many 
disciplines  and  forms  of  expertise  to  the  table  to  be  able  to  review  the  identified 
capability  gap  or  specified  need,  and  develop  the  requirements  to  be  incorporated  in  the 
appropriate  requirements  documents.  ICTs  are  used  for  the  development  and  writing  of 
each  requirement  document,  both  with  the  previous  RGS  and  now  with  JCIDS. 

Integrated  product  teams  (IPTs)  come  in  the  form  of  overarching  integrated 
product  teams  (OIPTs)  and  working-level  integrated  product  teams  (WIPTs).  Both  teams 
are  comprised  of  SMEs  from  several  functional  disciplines  to  build  a  successful  and 
balanced  program.  Additionally,  they  identify  and  resolve  issues,  and  provide 
recommendations  to  decision-makers.  OIPTs  focus  on  strategic  guidance,  program 
executability  (cost,  schedule,  risk),  and  issue  resolution  (U.S.  Army  War  College,  2011). 
Additionally,  OIPTs  are  used  as  subordinates  of  the  Defense  Acquisition  Board  (DAB) 
reviews.  They  analyze  material  alternatives  and  recommend  study  efforts  before  the 
DAB  convenes  (HQDA,  2009).  All  of  this  occurs  prior  to  the  MS  A  decision  for  approval 
and  review  of  concept  studies.  The  documents  used  by  the  OIPT  to  execute  their 
responsibilities  are  the  initial  requirement  documents,  the  MNS  or  ICD  (HQDA,  2009). 
However,  WIPTs  focus  on  particular  topics,  such  as  T&E,  cost/performance,  and  risk 
management  (U.S.  Army  War  College,  2011).  Focusing  on  the  topics  allows  WIPTs  to 
identify  and  resolve  issues,  determine  a  program’s  status,  and  seek  opportunities  for 
acquisition  reform  (U.S.  Army  War  College,  2011).  Members  of  the  WIPT  come  from 
HQDA  or  Service/functional  action  officers,  and  the  WIPT  is  chaired  by  the  PM  or  a 
selected  designee.  WIPTs  provide  advice  and  aid  the  PM  to  prepare  a  program’s  plan  and 
strategy  (U.S.  Army  War  College,  2011). 
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2. 


Combat  Developers/Capability  Developers 


This  entity  is  the  direct  representative  for  the  warfighter.  The  individuals  that 
compose  these  entities  can  be  acquisition  personnel,  branch- specific  personnel  for  the 
acquisition  program,  or  personnel  completely  outside  of  the  branch  that  are  tasked  to 
develop  and  write  the  materiel  requirements  documents.  All  of  these  personnel  are 
within  the  U.S.  Army  Training  and  Doctrine  Command  (TRADOC).  Additionally,  two 
Army  manuals  provide  different  titles  for  the  same  position  that  accomplishes  the  same 
mission  while  following  the  same  responsibilities.  Army  Regulation  71-9,  Warfighting 
Capabilities  Determination  (HQDA,  2009),  clearly  identifies  CMBTDEV  as  the 
requirements  writer  for  the  warfighter  who  resides  within  TRADOC.  However,  How  the 
Army  Runs  (2011-2012  ed.;  U.S.  Army  War  College,  2011)  identifies  this  entity  as  the 
Capability  Developer  (CAPDEV).  The  only  distinction  between  the  two  entities  is  their 
title.  For  this  project,  we  use  the  term  CBTDEV.  AR  71-9  (HQDA,  2009)  states 
CBTDEV’s  responsibilities  as  the  following: 

1.  Utilize  Army  and  Joint  capstone  concepts  to  develop  operating  and 
functional  concepts  detailing  how  the  Army  will  operate  as  part  of  a  Joint 
warfighting  force.  Link  the  concepts  to  Joint  capability  areas  (JCAs)  for 
relevancy  to  Joint  capability  needs.  Develop  component  cost  position 
(CCP)  as  required  to  define/refine  operational,  warfighting  requirements 
for  a  particular  warfighting  function  or  capability  area.  When  CCP  are 
required,  CCP  developers  will  outline  the  basic  capability  requirements  to 
provide  enough  detail  to  initiate  a  capabilities-based  assessment  as 
outlined  in  the  JCIDS  Manual.  All  concepts  must  illustrate  how  future 
forces  will  operate,  describe  the  capabilities  required  to  carry  out  a  range 
of  military  operations  against  adversaries  in  the  expected  Joint  operational 
environment,  and  how  a  commander,  using  military  art  and  science,  might 
employ  these  capabilities  to  achieve  desired  effects  and  objectives. 

2.  Utilize  the  contemporary  operational  environment  and  Joint  Operating 
Environment.  The  operational  environment  must  describe  the  composite 
of  conditions,  circumstances,  and  influences  that  affect  employment  of 
military  forces  and  bear  on  the  decisions  of  commanders.  It  depicts  the 
challenging,  adaptive  global  setting  the  U.S.  Army  military  will  encounter 
over  the  next  20  years  and  beyond,  and  provides  the  fundamental  context 
for  Army  and  Joint  experiments  and  training.  It  must  provide  the  essential 
foundation  for  developing  concepts  and  writing  requirements;  define  the 
threat  and  environment  for  individual  and  collective  training  across 
schools  and  combat  training  centers  (CTCs);  and  provide  benchmarks  for 
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comparing  risk,  effectiveness,  and  cost  in  potential  DOTMLPF  solutions 
and  for  testing  materiel  solutions  to  ensure  efficiency  and  effectiveness. 

3.  Ensure  only  validated  threat  assessments  are  used  in  concept 
development  and  any  modeling  efforts  supporting  capabilities 
determination. 

4.  Ensure  the  appropriate  experimentation  is  conducted  to  validate 
concepts.  (HQDA,  2009,  p.  8) 

CBTDEVs  are  involved  in  the  process  of  developing  and  writing  the  MNS  and  ORD 
from  the  RGS  process.  During  the  development  of  the  ORD,  they  serve  as  the  leader  from 
the  ICT  through  program  initiation,  which  includes  being  responsible  for  the  mission  area 
where  the  deficiency  or  opportunity  was  identified.  After  MS  C,  the  CBTDEV  is  responsible 
for  determining  if  a  need  exists  or  if  a  change  is  required  in  the  performance  envelope  within 
the  threshold  values  for  a  materiel  solution  captured  in  the  ORD. 

As  documents  changed  during  the  transition  from  the  RGS  to  the  JCIDS,  so  did  the 
CBTDEV’s  responsibilities  for  documents.  CBTDEVs  retained  the  same  developmental 
responsibilities  for  documents  as  in  the  RGS.  However,  in  JCIDS  they  are  responsible  for 
the  previously  listed  development  responsibilities,  but  the  input  medium  of  requirements 
documents  shifted  from  the  old  RGS  documents  to  the  ICD  and  CDD. 

3.  U.S.  Army  Training  and  Doctrine  Command 

As  the  main  developers  and  implementers  for  training  and  doctrine,  they  also 
have  a  role  within  the  process  of  developing  requirement  documents.  TRADOC 
examines  the  possibility  for  non-material  solutions,  material  solutions,  or  some 
combination  of  both  to  satisfy  a  specified  capability  gap.  Their  decision  is  based  on 
DOTmLPF-P.  In  this  regard,  TRADOC  examines  a  capability  gap  in  terms  of  functional 
area,  the  relevant  range  of  military  operations,  desired  effects,  time,  DOTMLPF,  and 
policy  implications  and  constraints  (HQDA,  2009).  The  analysis  requires  the 
development  KPPs.  These  are  the  essential  attributes  to  achieve  the  desired  capability. 
The  attributes  are  expressed  in  terms  and  values  of  thresholds  and  objectives.  The  values 
are  the  required  minimum  and  desired  maximum  capability  for  an  attribute’s  stated 
performance  within  a  given  performance  specification.  This  creates  a  small  range  of 
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flexibility  in  capability  that  the  program  manager  can  use  as  trade  space  between 
performance  and  cost.  Additionally,  KPPs  are  identified  in  the  CDD/CPD  directly 
traceable  to  attributes  identified  within  the  ICD. 

All  of  the  analysis,  such  as  the  capabilities  based  assessment,  from  TRADOC  is 
captured  in  the  ICD.  The  ICD  serves  as  the  medium  for  the  TRADOC  commander  to 
submit  an  evaluation  and  or  recommendation  to  Headquarters,  Department  of  the  Army 
(HQDA)  for  approval  (U.S.  Army  War  College,  2011).  TRADOC  also  assumes  the 
responsibility  for  submitting  additional  documents  throughout  the  RGP.  One  such 
document  is  the  Joint  Capabilities  Document  (JCD),  submitted  to  the  Army  deputy  chief 
of  staff  (DCS),  G-3/5/7  (HQDA,  2009).  TRADOC  outlines  KPPs,  key  system  attributes, 
and  other  attributes  within  the  document  (HQDA,  2009).  Finally,  TRADOC  uses  the 
CDD  to  develop  and  write  the  CPD,  which  is  submitted  to  the  DCS,  G-3/5/7  (HQDA, 
2009).  The  formats  for  the  documents  are  similar,  and  the  CPD  provides  the  number  of 
items  to  be  produced  for  fielding  based  on  the  analysis  of  what  is  needed  within  Army 
units’  MTO&Es. 

4.  Army  Deputy  Chief  of  Staff  (DCS),  G-3/5/7 

The  DCS,  G-3/5/7  serves  as  the  “current  and  Future  Warfighting  Capabilities 
Division  Gatekeeper  for  staff  coordination,  validation,  and  approval,  and  forwarding  to 
Joint  staffing”  (HQDA,  2009,  p.  20).  As  per  Army  Regulation  70-1,  DCS,  G-3/5/7  is  to 
“develop  Army  policy  and  guidance  for  materiel  requirements  and  capabilities 
development  programs,  to  include  the  development  and  integration  of  capabilities 
documents  and  horizontal  requirements  integration  processes”  (HQDA,  2011a,  p.  19). 
The  DCS,  G-3/5/7  performs  the  gatekeeper  role  for  the  ICD,  CDD,  and  CPD.  The 
gatekeeper  role  is  the  single  point  of  entry  and  exit  for  requirements  documents.  “Army 
Gatekeepers  manage  the  CAMS  [capability  and  AROC  management  system  tool]  to 
ensure  consistency  of  staff  coordination  as  JCIDS  proposals  progress  through  the 
validation  and  approval  process”  (HQDA,  2009,  p.  15).  All  requirements  documents  that 
are  submitted  for  review  and  approval  are  required  to  go  through  the  DCS,  G-3/5/7.  This 
is  the  entity  responsible  for  validating  and  integrating  a  DOTmLPF-P  review  (HQDA, 
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2011a).  Additionally,  the  DCS,  G- 3/5/7  conducts  an  evaluation  of  materiel  requirements 
and  critical  operational  issues  and  criteria  for  all  ACAT  programs  (HQDA,  201  la). 

5.  Headquarters,  Department  of  the  Army 

This  entity  was  responsible  for  managing  the  requirements  determination  process 
during  the  RGS.  It  served  as  the  approval  authority  for  materiel  requirements  through  the 
Army  Requirements  Oversight  Council  (AROC).  Additionally,  HQDA  validated  and 
approved  all  RGS  documents  (MNS,  CRD,  and  ORD).  As  the  approval  authority,  it  also 
examined  and  identified  possible  alternatives  to  meet  a  capability  gap  prior  to  entering 
MS  A.  However,  the  Joint  Requirements  Oversight  Council  (JROC)  approves 
Acquisition  Category  (ACAT)  ID  or  Joint  or  other  Service- specific  programs  (HQDA, 
2009).  Although  the  JROC  serves  as  the  approval  authority  for  main  ACAT  programs, 
some  approval  is  left  with  the  Services.  Some  capability  documents  are  validated  by  the 
Services  based  on  the  level  of  the  ACAT  program,  which  also  takes  into  account  the  cost 
of  the  particular  acquisition  program. 

6.  Army  Requirements  Oversight  Council 

The  Army  Requirements  Oversight  Council  (AROC)  is  responsible  for  reviewing 
all  requirements  that  went  into  the  materiel  requirements  documents.  For  the  RGS 
process,  this  was  the  MNS  document  and  now  for  the  JCIDS  process  this  is  the  ICD. 
Additionally,  the  AROC  approves  the  CDD  and  CPD  as  well.  Plus,  the  Council  is 
responsible  for  evaluating  the  relevancy  of  materiel  requirements  for  the  Army’s  needs. 
The  Vice  Chief  of  Staff  of  the  Army  (VCSA)  serves  as  the  AROC’s  chair  during  both  the 
JCIDS  and  the  previous  RGS  process.  The  council  considers  requirements  in  terms  of 
affordability  and  interoperability.  Additionally,  the  AROC  advises  the  Chief  of  Staff  of 
the  Army  (CSA)  on  warfighting  requirements.  The  AROC  consists  of  the  following 
permanent  principal  members: 

Vice  Chief  of  Staff,  Army  (Chair) 

Military  Deputy,  Office  of  the  Assistant  Secretary  of  Army  (Acquisition, 

Logistics,  and  Technology) 
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Chief  Information  Officer  (CIO)/Deputy  Chief  of  Staff,  G-6 

Deputy  Chief  of  Staff,  G-l 

Deputy  Chief  of  Staff,  G-2 

Deputy  Chief  of  Staff,  G-3/5/7  (Secretary) 

Deputy  Chief  of  Staff,  G-4 
Deputy  Chief  of  Staff,  G-8 

Director,  Army  Capabilities  Integration  Center  (ARCIC) 

Deputy  Assistant  Secretary  of  the  Army,  Cost  &  Economics 

CG,  Army  Test  and  Evaluation  Command  (ATEC).  (U.S.  Army  War 
College,  2011,  p.  217) 

7.  Joint  Requirements  Oversight  Council 

The  Council  reviews  and  validates  that  a  mission  is  incapable  of  being  satisfied 
through  a  non-material  solution.  In  this  role,  the  Council  recommends  warfighting 
capabilities  and  requirements  for  acquisition  programs.  Additionally,  the  Joint 
Requirements  Oversight  Council  (JROC)  assigns  Joint  priorities  among  major  programs 
with  valid  requirements  identified  by  CCDRs,  Services  and  others.  Based  on  assigned 
priorities,  the  Council  identifies,  evaluates,  and  designates  potential  candidates  for  Joint 
acquisition  programs  while  resolving  requirement  issues  across  the  Services.  One  of  the 
more  critical  functions  of  the  JROC  is  to  “review  military  needs  and  acquisition  programs 
with  emphasis  on  ensuring  interoperability,  pursuing  opportunities  for  Joint  or  multi- 
Service  applications,  eliminating  unnecessary  duplication,  and  promoting  cost  savings” 
(HQDA,  2009,  p.  18). 

During  the  RGS,  the  JROC’s  role  was  slightly  different  when  dealing  with  the 
requirement  documents.  The  JROC  would  examine  the  validity  of  the  identified  need, 
assign  joint  priority  when  appropriate,  and  forward  the  MNS  to  the  USD(AT&L)  for 
action.  However,  the  JROC  was  the  approval  authority  for  the  ORDs  for  ACAT  ID 
programs. 
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The  JROC’s  focus  for  documents  changed  as  the  transition  to  the  JCIDS  occurred. 
In  JCIDS,  the  JROC  is  responsible  for  identifying  and  prioritizing  warfighter 
requirements.  As  the  council  validates  and  approves  KPPs,  even  when  the  authority  for 
the  capabilities  documents  has  been  delegated  to  the  Army  (HQDA,  2009).  Additionally, 
the  JROC  ensures  the  KPP  attributes  are  expressed  with  a  threshold  and  objective  values. 
In  addition  to  KPP  approval,  the  JROC  has  “...advisory  responsibilities  to  the  CJCS  in 
identifying,  assessing,  validating,  and  prioritizing  joint  military  capability  requirements” 
(JROC,  2012b,  p.  2).  Additionally,  the  JROC  became  the  approval  authority  for  the  ICD. 
Approval  of  the  capability  document  does  not  mean  the  JROC  has  the  ultimate  decision 
on  whether  a  non-materiel  or  a  materiel  solution  should  be  pursued.  Instead,  they  provide 
advice  to  the  MDA  on  an  approach  that  best  satisfies  the  capability  requirement  (JROC, 
2012b).  The  MDA  is  the  ultimate  approving  authority  to  pursue  a  materiel  solution  or  to 
go  with  a  non-materiel  solution. 

The  main  differences  for  the  JROC’s  responsibilities  between  the  RGS  and  the 
JCIDS  are  identified  in  Table  3.  The  table  shows  the  JROC’s  actions  for  each  of  the 
processes.  Although  some  of  the  processes  and  responsibilities  changed,  one  main 
responsibility  remained  intact.  The  JROC  was  and  still  is  the  reviewing  and  approving 
authority  for  requirements  documents. 


Table  3.  JROC  Responsibilities  in  the  RGS  and  JCIDS  Processes 


RGS 

JCIDS 

Validates  need  and  assigns 
priority 

Identifies  and  prioritizes  requirements 

Forwards  MNS  to  USD(AT&L) 

Provides  approval  authority  for  ICD 

Approves  AC  AT  ID  ORDs 

Recommends  materiel/non-materiel  solutions 

Validates  KPPs 

Ensures  attributes  have  thresholds  &  objectives 

Figure  12  displays  the  flow  of  the  documents  from  each  of  the  stakeholders  to  the 
approval  authority.  The  starting  point  is  with  TRADOC,  where  the  CBTDEVs  reside, 
and  the  final  approval  ends  with  the  JROC.  The  figure  can  be  found  in  Army  Regulation 
71-9,  Warfighting  Capabilities  Determination  (HQDA,  2009). 
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Figure  12.  JCIDS  Validation  and  Approval  Process  (From  HQDA,  2009,  p.  18) 


8.  Milestone  Decision  Authority 

The  milestone  decision  authority  (MDA)  serves  as  the  main  approval  authority  for 
an  acquisition  program  to  begin  or  proceed  to  the  next  phase  within  the  acquisition  life 
cycle.  The  MDA  is  responsible  for  reviewing  and  evaluating  requirements  and 
documents,  while  paying  particular  attention  to  military  needs  and  risk,  synchronization 
with  Army  Modernization  and  Transformation  Campaign  plans,  and  affordability  and 
interoperability  (U.S.  Army  War  College,  2011).  Additionally,  the  MDA  is  responsible 
for  issuing  the  acquisition  decision  memorandum  (ADM)  at  the  material  development 
decision  (MDD).  The  ADM  determines  at  what  phase  an  acquisition  program  enters  into 
the  acquisition  life  cycle,  whether  that  is  at  MSA,  TD,  EMD  or  P&D.  Entry  into  the  MSA 
phase  requires  the  following  to  occur:  concept  studies  are  initiated,  a  lead  agency  is 
designated,  and  concept  exploration  exit  criteria  are  approved  (U.S.  Army  War  College, 
2011).  Starting  in  the  EMD  or  P&D  phases  is  based  on  the  MDA’s  decision  from 
provided  reviews  of  technology  readiness  levels  (TRLs)  and  based  on  whether 
component  development  is  still  needed  (U.S.  Army  War  College,  2011).  In  conjunction 
with  all  of  these  responsibilities,  the  MDA  identifies  the  minimum  documentation  for 
milestone  review  (U.S.  Army  War  College,  2011). 
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9.  Materiel  Developer 

The  personnel  that  compose  this  entity  are  normally  within  the  acquisition 
program’s  office.  This  body  used  the  ORD,  and  now  uses  the  CDD,  for  developing 
system  performance  requirements  for  contract  specifications  during  each  acquisition 
phase.  The  materiel  developer  (MATDEV)  translates  the  CBTDEV  requirements,  based 
on  the  warfighter’s  needs,  into  performance  requirements  or  specifications  from  the 
requirements  listed  in  the  ORD  and  CDD. 

10.  Program  Executive  Office,  Program  Manager,  and  Other  Associated 
Managers 

Several  echelons  of  personnel  exist  within  any  given  program  office.  Using  the 
Ground  Combat  System  (GCS)  program  office  as  an  example,  we  show  how  the 
hierarchy  appears  in  a  program.  The  program  executive  officer  (PEO)  is  the  main  person 
in  charge  of  the  overall  program.  Program  managers  (PMs)  fall  into  the  next  level.  PMs 
are  in  charge  of  specific  vehicle  platforms  such  as  the  Joint  Lightweight  Tactical  Vehicle 
(JLTV)  or  the  Stryker  vehicle.  Other  associated  managers  are  the  different  product 
managers.  In  the  case  of  the  Stryker  vehicle  program,  this  is  the  person  in  charge  of  the 
infantry  carrying  vehicle  (ICV)  variant  or  the  mobile  gun  system  (MGS)  variant.  Serving 
as  the  leaders  of  the  program/product  causes  each  of  these  personnel  to  have  many 
assigned  responsibilities  within  JCIDS.  However,  we  will  focus  on  their  roles  and 
responsibilities  with  requirements  documents.  The  main  role  PEOs,  PMs,  and  others 
serve  is  as  the  executor  of  approved  requirements  documents. 

One  of  their  foremost  responsibilities  with  requirement  documents  is  to  assist  the 
CBTDEV  with  developing  CDDs  and  CPDs.  They  aid  in  providing  schedule, 
performance,  estimated  materiel  acquisition  cost,  availability,  and  technical  information 
(HQDA,  2009).  Additionally,  they  incorporate  capabilities  for  system  training  into  the 
materiel  system  in  compliance  with  the  approved  CDD  and  CPD,  while  integrating 
involvement  from  the  CBTDEV  and  TNGDEV  (HQDA,  2009).  Another  responsibility  is 
the  creation  of  the  request  for  proposal  (REP)  based  on  the  approved  CDD  and  CPD. 
This  occurs  through  coordination  with  the  CBTDEV  and  by  conducting  a  crosswalk  of 
the  CDD  and  CPD  to  ensure  all  specifications  and  statements  of  work  (SOWs)  accurately 
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reflect  the  operational  requirements.  Once  this  occurs,  the  CBTDEV  then  certifies  the 
RFP  prior  to  the  program  or  OIPT  review  (HQDA,  2009). 

Although  many  of  the  roles  of  the  PEO,  PM,  and  others  occur  with  the  CDD  and 
CPD,  they  do  have  a  role  earlier  in  the  process.  They  lead  the  IPT  for  cost  performance. 
Additionally,  they  institute  cost  as  an  independent  variable.  Cost  as  an  independent 
variable  allows  the  managers  to  examine  what  the  associated  cost  would  be  for  a  specific 
level  of  performance  stated  within  the  requirements  documents.  This  allows  the  ability  to 
monitor  cost  and  possibly  produce  savings  by  mapping  out  the  associated  costs  at  the 
threshold  and  objective  levels  of  performance.  The  PM  can  then  conduct  analysis  on 
how  to  best  achieve  the  requirements  expressed  within  the  documents  to  achieve  cost 
savings  to  the  government.  Cost  savings  is  achieved  by  the  tradeoff  space  between  the 
threshold  and  objective  values.  Another  responsibility  they  have  with  the  ICD  and  CDD 
is  to  translate  the  requirements  in  these  documents  into  system  specifications  and  designs 
that  are  testable  and  verifiable  (U.S.  Army  War  College,  2011).  Plus,  the  personnel  give 
the  MATDEV  perspective  when  providing  recommendations  to  Army  Modernization 
Plans  (HQDA,  2009). 

11.  Summary 

In  summation,  many  stakeholders  are  involved  throughout  the  development  of 
any  one  materiel  requirement  document.  Special  care  of  the  information  placed  in  a 
requirement  document  is  a  necessity.  Both  the  stakeholders  and  the  users  use  this 
information.  A  lack  of  information  or  poor  quality  of  information  can  pose  a  severe 
strain  on  the  users  as  they  execute  the  documents  for  their  acquisition  program.  Table  4 
captures  the  stakeholders  and  users  and  displays  their  role(s)  for  a  particular  document. 
This  is  a  helpful  visual  aid  to  see  how  entities  have  multiple  roles  for  a  particular 
document. 
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Table  4.  Stakeholders  and  Their  Roles  for  Materiel  Requirement  Documents 


Developer 
/  Writer 

Input / 
Guidance 

Reviewer 

Approver 

Executer 

Individual 

Stakeholders 

CBTDEV  /  TNGDEV 
(TRADOC) 

X 

X 

X 

DCS,  G-3/5/7 

X 

X 

CSA  /  VCSA 

X 

MATDEV 

X 

X 

X 

PM 

X 

X 

PEO 

X 

X 

Groups  /  Council 
Stakeholders 

ICT 

X 

X 

X 

IPT 

X 

X 

X 

OIPT 

X 

X 

AROC 

X 

X 

HQDA  -  CSA  /  VCSA 

X 

JROC 

X 

X 

In  addition.  Table  4  helps  illustrate  the  multiple  connecting  roles  that  exist  and 
how  important  the  correct  information  is  within  each  requirement  document. 
Stakeholders,  such  as  the  MATDEV  and  PM,  are  involved  with  each  of  the  requirements 
documents  throughout  the  entire  JCIDS  process.  Thus,  correct,  concise,  and  clear 
information  allows  for  a  successful  acquisition  program  that  provides  the  warfighter  with 
a  system  or  piece  of  equipment  that  meets  its  desired  need. 

F.  CHAPTER  SUMMARY 

Overall,  CJCSI  3170.01  has  evolved  from  CJCSI  3170.01C  (CJCS,  2003)  to 
CJCSI  3170.01H  (CJCS,  2012).  The  requirements  documents  have  continuously  evolved 
with  more  precise  regulations  and  formats.  CJCSI  3170.01  version  C  was  published  in 
2003,  verision  D  in  2004,  version  E  in  2005,  version  F  in  2007,  version  G  in  2009,  and 
the  most  recent  version  H  in  2012.  These  evolutionary  changes  were  refinements  to  the 
JCIDS  process  over  a  span  of  nine  years  to  improve  efficiency  in  the  RGP.  The  intent  to 
redefine  these  requirements  documents  has  been  to  systematically  focus  the  requirements 
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of  the  warfighter  in  order  to  accommodate  the  rigors  of  the  Anny’s  acquisition  process. 
A  change  was  necessary  to  shift  concepts  from  requirements  based  to  capabilities  based. 
Emerging  capability  gaps  were  rapidly  being  identified  as  materiel  and  non-materiel 
solutions  attempted  to  keep  up  with  the  inflow.  The  key  stakeholders  involved  in  the 
RGP  did  not  need  to  know  what  warfighters  wanted,  but  the  capability  that  the 
warfighters  needed  to  execute  their  missions. 

The  next  chapter  reveals  our  comparative  analysis  of  ground  vehicle  programs 
that  have  been  developed  under  both  the  RGS  and  the  JCIDS.  We  have  conducted 
qualitative  analysis  of  materiel  requirements  documents  on  pre-GWOT  platforms, 
GWOT  platforms,  and  future  post-GWOT  platforms.  Additionally,  we  draw  conclusions 
about  future  considerations  for  efficient  and  effective  materiel  requirements  documents. 
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III.  RESEARCH  METHODOLOGY 


In  this  chapter,  we  outline  the  detailed  research  methodology  that  we  selected  in 
order  to  execute  and  meet  the  project’s  intent.  The  research  methodology  was 
constructed  based  on  the  data  provided  in  Chapter  II,  Background,  and  on  the  documents 
related  to  three  specific  Army  vehicle  programs:  HMMWV,  M-ATV,  and  JLTV. 
Furthermore,  our  methodology  leads  into  the  comparative  analysis  we  implemented  that, 
ultimately,  allowed  us  to  formulate  our  conclusions  and  recommendations. 

A.  RESEARCH  PURPOSE 

The  purpose  of  our  research  is  to  propose  future  changes  to  enhance  the  efficiency 
and  effectiveness  of  the  U.S.  Army’s  materiel  capabilities  documents  (MCDs)  used  to 
facilitate  materiel  solutions.  Our  recommendations  are  developed  by  a  comparative  analysis 
of  the  Army’s  past  and  present  MCDs  and  their  efficiency  in  their  respective  requirements 
generation  processes  (RGPs).  “Like  other  analytical  methods  in  qualitative  research, 
document  analysis  requires  that  data  be  examined  and  interpreted  in  order  to  elicit  meaning, 
gain  understanding,  and  develop  empirical  knowledge”  (Bowen,  2009,  p.  27). 

A  comparative  analysis  of  MRDs  from  the  RGS  period,  prior  to  June  2003,  to 
MCDs  from  the  current  JCIDS  period,  provided  us  with  the  necessary  data  to  gain 
understanding  and  develop  recommendations  for  change.  The  evaluation  compares  the 
RGS’s  primary  MRDs  (MNS,  ORD-Initial,  and  ORD-Revised)  to  the  JCIDS’  primary 
MCDs  (ICD,  CDD,  and  CPD).  Inclusive  to  the  assessment  are  the  implementation  of 
other  MRDs/MCDs  used  for  a  more  rapid  procurement  of  an  identified  materiel  solution. 
These  documents  are  the  ONS,  UONS,  and  JUONS. 

Our  comparative  analysis  identifies  the  strengths  and  weaknesses  of  each  document 
in  relation  to  the  stakeholders,  associated  timelines,  and  redundancies  within  the  RGP. 
Additionally,  we  have  identified  benefits  and  types  of  change  required  for  implementation 
of  our  recommendations.  Our  project’s  predominant  purpose  is  to  provide 
recommendations  for  enhanced  MCDs  for  the  future  Army’s  RGP.  To  accomplish  this 
purpose,  we  have  used  a  six-step  research  methodology  based  on  the  Client  Opinions 

55 


Model  (Client  Opinions,  n.d.),  and  may  be  better  comprehended  with  the  aid  of  Figure  13. 
Additionally,  we  have  tailored  this  model  to  project  to  enhance  our  analysis. 


Figure  13.  Six  Steps  of  Research  Methodology  (After  Client  Opinions,  n.d.) 


B.  APPROACH  TO  RESEARCH 

Our  research  project  used  qualitative  data,  gathered  from  key  stakeholders  and 
subject-matter  experts  who  have  either  undergone  or  are  undergoing  the  implementation 
of  MRDs/MCDs  throughout  the  life  cycle  of  ACAT  I  programs.  We  have  conducted  a 
comparative  analysis  of  MRDs/MCDs  from  three  Army  vehicle  programs. 

Our  research  is  broken  down  by  five  distinctive  qualitative  approaches  based  on 
qualitative  research  designs  from  Lindquists  (n.d.):  (1)  Historical,  (2)  Phenomenology, 
(3)  Grounded  Theory,  (4)  Ethnography,  and  (5)  Case  Study. 

An  historical  approach  examines  key  activities  and  events  from  the  past  of  the 
RGP.  We  have  been  able  to  understand  the  evolution  of  the  RGP  to  the  present  JCIDS 
process,  as  well  as  project  the  potential  evolution  of  future  RGP  initiatives.  We  have 
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been  able  to  gain  this  understanding  by  studying  past  DoD  policies,  documents, 
regulations,  doctrine,  studies,  reports,  and  programs.  The  historical  data  have  allowed  us 
to  develop  our  research  questions  and  ideas.  We  have  analyzed  the  quality  and  reliability 
of  this  data  and  developed  an  opinion  on  what  has  been  beneficial  in  the  past,  and  what 
factors  have  constrained  the  RGP.  By  doing  so,  we  have  also  been  able  to  develop  and 
refine  the  organization  of  our  research  methodology  and  how  we  have  continued  to 
gather  additional  data  that  we  formulated  in  our  interview  questions.  The  historical 
approach  has  also  allowed  us  to  recognize  contradicting  data  necessary  to  analyze  the 
evolution  of  the  RGP  that  was  crucial  to  reaching  our  recommendations  in  this  project. 
Ultimately,  this  approach  defines  our  ability  to  present  our  information  in  the  most 
effective  order. 

The  stakeholders  primarily  drive  the  phenomenology  approach.  We  have  utilized 
this  approach  to  construct  our  list  of  interviewees  and  interview  questions,  and  to  guide 
conversations  with  our  selected  stakeholders.  Our  goal  with  the  approach  is  to 
understand  the  experiences  of  those  who  have  had  key  roles  in  past  MRDs  and  who  are 
currently  executing  MCDs,  and  to  project  the  effects  of  future  changes  to  MCDs.  These 
stakeholders  are  defined  by  their  uniqueness.  Uniqueness  is  identified  by  the 
stakeholders’  relationship  to  and  level  of  involvement  with  requirements  documents.  The 
phenomenology  approach  has  allowed  us  to  maximize  our  creative  methods  and  has 
required  the  most  personal  interaction  in  our  research  methodology.  We  have  had  to 
understand  not  only  the  data  collected  from  recorded  interviews  but  also  our 
interviewees’  duty  positions  and  levels  of  responsibilities  to  truly  understand  their  points 
of  view.  Patterns,  habits,  and  themes  are  the  primary  outcomes  from  this  qualitative 
approach.  We  are  better  able  to  reach  our  recommendations  and  conclusions  by 
comprehending  the  outcomes  of  this  analysis. 

The  grounded  theory  approach  allows  us  to  develop  our  understanding  of  the  RGP 
that  inevitably  led  us  to  our  recommendations.  This  approach  identifies  what  the 
standard  should  be  that  benefits  the  preponderance  of  the  stakeholders’  needs.  By 
understanding  what  should  be  the  standard,  we  have  been  able  to  identify  the  deviations 
from  the  standard,  to  understand  why  the  deviations  exist,  and  to  recommend  how  to 
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minimize  these  deviations.  Much  of  our  use  of  grounded  theory  is  focused  on  the  staffing 
and  bureaucracy  internal  to  the  RGP.  Grounded  theory  requires  a  continuous  cycle  of 
comparative  analysis  between  documents,  processes,  stakeholders,  and  collected  data. 
All  of  this  comparative  analysis  is  nested  to  the  core  concepts  and  intent  of  the  RGP.  Our 
approach  to  grounded  theory  has  been  based  on  our  evolving  observations  and  opinions 
of  the  key  stakeholders.  We  have  been  able  to  scope  down  and  modify  our 
recommendations  by  using  this  qualitative  approach. 

The  ethnography  approach  has  allowed  us  to  understand  the  characteristics  of  the 
RGP  culture,  both  internal  and  external  to  the  DoD.  Using  the  ethnography  approach,  we 
have  developed  our  understanding  of  the  organization  of  the  DoD  RGP  from  authors, 
staffers,  approvers,  and  executers  of  MRDs/MCDs.  We  have  also  been  able  to  recognize 
the  efficiencies  and  effectiveness  of  processes  from  the  past  and  the  present,  and  to 
project  recommendations  for  the  future.  Evolutionary  and  revolutionary  changes  are  the 
concepts  we  have  derived  from  this  approach,  and  implementation  of  changes  is  the  result 
of  this  method.  The  ethnography  approach  has  provided  us  with  the  necessary 
comprehension  of  the  required  culture  changes  that  must  occur  to  improve  MCDs. 

The  case  study  approach  has  been  our  overarching  method  to  tie  in  all  of  the  other 
four  approaches.  This  approach  guided  us  to  choose  our  three  ground  vehicle  platforms 
of  the  HMMWV,  M-ATV,  and  JLTV.  We  are  able  to  focus  our  analysis  by  interviewing 
those  stakeholders  involved  with  these  three  platforms.  The  case  study  approach  has 
allowed  us  to  synthesize  the  experience  of  these  platforms’  life  cycle  within  the 
limitations  of  their  supporting  MRDs/MCDs.  This  has  provided  us  with  the  necessary  in- 
depth  understanding  that  has  allowed  us  to  define  our  conclusions  and  recommendations. 

In  understanding  the  efficiency  and  effectiveness  of  MRDs/MCDs,  we  utilize  the 
five  distinctive  approaches.  We  analyze  the  RGP’s  MRDs/MCDs,  the  MRDs/MCDs 
efficiency  to  facilitate  past  and  present  materiel  RGPs,  and  data  collected  through 
interviews  with  subject-matter  experts.  “The  qualitative  researcher  is  expected  to  draw 
upon  multiple  (at  least  two)  sources  of  evidence;  that  is,  to  seek  convergence  and 
corroboration  through  the  use  of  different  data  sources  and  methods”  (Bowen,  2009,  p. 

28).  We  selected  multiple  sources  based  on  the  acquisition  programs  we  analyzed. 
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Data  gathered  during  our  initial  research  for  background  information  provided 
support  and  understanding  for  our  analysis  of  the  collected  data.  Background 
information  provides  the  basis  for  the  evaluation  and  critique  when  analyzing 
requirement  documents  from  the  different  periods  of  the  RGP.  In  addition,  the  RGS  and 
JCIDS  processes  are  differentiated  in  order  to  gain  a  better  understanding  of  how  the 
different  materiel  solution  requirements  documents  nest  within  the  two  separate  processes 
for  requirements  generation.  Army  and  Joint  policies’  purposes  and  required  formats  for 
MRDs  and  MCDs  are  discussed  to  provide  detailed  information  on  each  document  and 
process.  Finally,  stakeholders  are  identified.  Information  on  stakeholders  provides 
insight  for  those  responsible  for  generating,  staffing,  validating,  approving,  and  executing 
the  MRDs/MCDs.  Researched  background  information  is  essential  for  conducting  the 
evaluation  and  analysis  of  these  crucial  documents. 

Interviews  from  subject-matter  experts  and  stakeholders  were  used  to  gain  the 
insights  of  those  directly  associated  with  the  documents.  The  interviewees  varied  from 
those  stakeholders  who  have  been  directly  involved  with  the  MRDs/MCDs  to 
stakeholders  currently  executing  the  approved  MRDs/MCDs.  Individuals  were  selected 
from  Program  Management  (PM)  Offices  for  the  HMMWV,  JLTV,  and  M-ATV.  We 
also  interviewed  key  leaders  associated  with  the  overall  acquisition  processes  from  the 
Program  Executive  Office  Combat  Support  and  Combat  Service  Support  (PEO  CS&CSS) 
and  from  the  Pentagon  that  are  associated  with  the  Chief  of  Capabilities  and  Acquisition 
Division  Joint  Staff  J8.  Opinions  from  interviewees  provided  insight  for  the  concepts  we 
assessed  in  our  examination  of  the  requirement  documents. 

Each  vehicle  program  is  used  as  a  case  study,  and  provided  requirement 
documents  used  during  a  particular  period  of  the  RGP.  Compiling  the  documents  into  a 
case  study  provided  the  necessary  data  for  reviewing  and  analyzing  each  of  the  different 
MRDs/MCDs. 

C.  INTERVIEWS 

One  part  of  being  able  to  understand  and  analyze  requirement  documents  is 
drawing  on  the  experience  of  subject-matter  experts  (SMEs)  currently  in  the  program 
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office  and  other  areas  of  the  acquisition  community.  SMEs  are  stakeholders  for  the 
requirement  documents  that  are  specific  to  the  HMMWV,  JLTV  and  MRAP  /  M-ATV 
programs  as  well  as  other  individuals  that  are  or  were  directly  involved  with  the  Army 
RGPs.  Interviews  were  conducted  with  personnel  serving  as  leaders  in  the  upper 
echelons  of  the  acquisition  career  field  and  personnel  directly  associated  with  the  vehicle 
programs.  This  information  provided  experience,  insight  and  opinions  on  what  makes  a 
requirement  document  “good”  through  the  interviewed  SME’s  eyes.  Additionally,  the 
SMEs  for  each  of  the  vehicle  platforms  were  able  to  provide  insight  and  experience  on 
the  efficiency  and  effectiveness  of  the  requirements  documents  for  their  programs.  The 
SMEs  also  provided  the  necessary  information  to  rate  the  efficiency  and  effectiveness  of 
the  requirements  documents  for  their  respective  vehicle  platforms  and  how  well  the 
requirements  documents  met  the  Better  Buying  Power  (BBP)  2.0  initiatives. 

The  SMEs  selected  for  this  project  came  from  past  and  present  professionals  from 
three  vehicle  programs  as  well  as  the  upper  echelon  leadership  who  have  been  directly 
involved  with  the  RGP.  However,  limitations  in  our  research  did  not  afford  the 
opportunity  to  interview  the  CBTDEV  from  TRADOC  to  fully  encompass  all 
stakeholders.  The  interviews  and  our  analysis  were  primarily  from  the  program  offices’ 
perspective.  For  the  HMMWV  program,  Brad  Naegle,  Senior  Lecturer  at  the  Naval 
Postgraduate  School  and  former  PM  for  HMMWV,  and  COL  Kevin  Peterson,  Chief  of 
Capabilities  and  Acquisition  Division  Joint  Staff  J8,  former  military  deputy  program 
manager  and  program  manager  for  MRAP  and  former  product  manager  for  HMMWV, 
were  interviewed.  M-ATV  interviews  came  from  Dave  Krawchuk,  chief  engineer  for  the 
JPO  MRAP  and  former  deputy  program  manager  for  the  M-ATV,  Michelle  Minto,  Lead 
Systems  Engineer  for  the  MRAP  program  and  MAJ  Anh  Ha,  former  assistant  product 
manager  for  M-ATV.  The  program  manager  for  tactical  vehicles  and  the  former  joint 
project  manager  for  JLTV  was  interviewed,  COL  David  Bassett.  Additionally,  Kevin 
Fahey,  PEO  for  Combat  Support  and  Combat  Service  Support  vehicles  was  interviewed. 
People  outside  of  the  acquisition  program  offices  interviewed  for  information  pertaining 
to  the  RGS  and  JCIDS  processes  were:  Major  General  Harry  Greene,  Deputy  for 
Acquisition  and  Systems  Management  (U.S.  Army)  and  Assistant  Secretary  of  the  Army 
for  Acquisition,  Logistics,  and  Technology,  Paul  Mann  /  SES,  OUSD(AT&L)/  Assistant 
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Director,  Land  Warfare  &  Munitions  and  former  MRAP  program  manager,  Timothy 
Goddette,  U.S.  Army  Director  Combat  Sustainment  Systems,  and  Michael  Aldridge,  J8 
staff  (Requirements  Analyst,  JUONS/JEONS,  Joint  Capabilities  Division). 

Interview  questions  used  to  collect  data  for  the  qualitative  analysis  can  be  found 
in  the  Appendix.  The  following  SMEs  were  interviewed  using  Appendix  A:  Major 
General  Harry  Greene,  Paul  Mann,  Timothy  Goddette,  and  Michael  Aldridge.  Appendix 
B  interview  questions  were  used  for  these  SMEs:  Brad  Naegle,  COL  Kevin  Peterson, 
Dave  Krawchuk,  Michelle  Minto,  MAJ  Anh  Ha,  COL  David  Bassett,  and  Kevin  Fahey. 

Each  person  selected  as  a  possible  interviewee  participated  voluntarily  and  was 
not  coerced  into  conducting  the  interview.  Interviewees  received  no  compensation  or 
reimbursement  of  any  kind  for  participating  in  the  research.  The  Naval  Postgraduate 
School’s  Acquisition  Research  Program  has  provided  full  transcription  of  the  interviews 
conducted  by  the  research  team  with  selected  interviewees.  No  alteration  of  interview 
results  occurred. 

D.  CASE  STUDIES 

We  used  existing  acquisition  programs  as  our  sources  to  obtain  requirements 
documents.  Additionally,  we  used  the  requirements  documents  from  these  programs  to 
conduct  an  analysis  and  answer  the  proposed  primary  and  secondary  research  questions. 
Due  to  this,  the  term  case  study  refers  to  the  selected  acquisition  programs  and  the  data 
obtained  and  reviewed  for  each  specific  program.  The  selected  three  vehicle  programs 
provided  us  with  the  desired  requirement  documents.  In  Chapter  IV,  we  present  a 
discussion  of  each  vehicle’s  acquisition  program.  Using  this  discussion,  we  have  been 
able  to  lay  out  where  the  vehicles  are  within  their  respective  acquisition  cycle,  the  RGP 
by  which  they  were  initiated,  the  system  they  are  currently  following,  the  requirement 
documents  used  in  the  vehicle’s  program,  and  any  successes  or  challenges  the  vehicle  has 
experienced. 

The  first  case  study  is  the  HMMWV.  From  this  case  study  we  extracted 
requirements  documents  related  to  the  RGP  period  prior  to  2003.  This  is  the  period  when 
the  RGS  was  in  effect  and  was  enhanced  when  the  JCIDS  process  came  into  effect. 
Second,  the  M-ATV  case  provides  MCDs  after  the  2003  RGP  period.  The  M-ATV 
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program  also  provides  documents  related  to  the  JUONS  process.  Last,  the  JLTV 
acquisition  program  came  into  existence  prior  to  2003  and  reached  MS  B  after  the 
implementation  of  the  JCIDS.  The  program  has  crossed  over  both  the  RGS  and  JCIDS 
processes.  Due  to  the  cross  over,  we  analyzed  documents  written  for  both  processes. 
These  three  ground  wheeled- vehicle  programs  are  the  source  of  our  understanding  of  the 
efficiency  of  MRDs/MCDs. 

E.  DOCUMENT  ANALYSIS  AND  COMPARISON 

Our  document  analysis  and  comparison  occurred  according  to  the  five  principles 
outlined  and  extracted  from  Glenn  Bowen’s  (2009)  article  “Document  Analysis  as  a 
Qualitative  Research  Method.” 

First,  as  indicated  above  [in  a  previous  section  of  Bowen’s  article], 
documents  can  provide  data  on  the  context  within  which  research 
participants  operate — a  case  of  text  providing  context,  if  one  might  turn  a 
phrase. 

Second,  information  contained  in  documents  can  suggest  some  questions 
that  need  to  be  asked  and  situations  that  need  to  be  observed  as  part  of  the 
research. 

Third,  documents  provide  supplementary  research  data. 

Fourth,  documents  provide  a  means  of  tracking  change  and  development. 

Fifth,  documents  can  be  analyzed  as  a  way  to  verify  findings  or 
corroborate  evidence  from  other  sources.  (2009,  pp.  29-30) 

Each  step  provides  us  with  the  necessary  technique  to  generate  useful  and  relevant  data 
from  our  analysis  of  the  documents.  A  thorough  and  useful  analysis  is  provided  because 
we  have  followed  each  of  these  principles. 

Additionally,  we  have  linked  our  analysis  to  the  BBP  2.0  initiatives.  We 
identified  five  key  initiatives  directly  related  to  the  generation  of  requirements  to  the 
requirements  documents  used  in  our  case  studies.  The  correlation  between  the 
documents  and  the  BBP  initiatives  in  order  to  assess  efficiencies  and  effectiveness  helped 
us  arrive  to  our  conclusion  and  recommendations. 
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F.  CHAPTER  SUMMARY 

In  this  chapter,  we  outlined  the  methodology  we  used  for  this  project.  In  Chapter 
IV,  we  present  the  case  studies  of  the  three  vehicle  platforms  used  for  this  project.  We 
also  provide  an  overview  of  each  platform’s  mission,  the  associated  requirements 
documents  used  for  each  platform,  and  data  collected  from  stakeholders  who  have  been 
directly  involved  in  the  creation  of  the  wheeled  vehicles.  Finally,  we  provide  a  rating  of 
the  requirements  documents  used  in  each  vehicle  platform  and  a  summarized  comparison 
for  efficiency,  effectiveness  and  BBP  2.0  initiatives. 
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IV.  CASE  STUDIES  AND  ANALYSIS 


In  this  chapter,  we  display  our  analysis  and  the  findings  from  our  research.  We 
have  used  the  techniques  outlined  in  our  third  chapter.  Methodology,  which  described  the 
five  distinctive  qualitative  approaches  we  are  focusing  on,  which  are  (1)  Historical,  (2) 
Phenomenology,  (3)  Grounded  Theory,  (4)  Ethnography,  and  (5)  Case  Study.  First,  for 
the  historical  approach  we  have  collected  data  from  past  reports,  requirements 
documents,  records,  and  other  professional  studies.  Second,  we  have  conducted  multiple 
interviews  with  SMEs  and  stakeholders  (refer  to  interview  section  in  Chapter  III.C),  and 
have  assessed  our  own  personal  experience  to  gather  information  to  support  the 
phenomenology  approach.  Third,  we  used  the  baseline  of  the  RGS  and  its  supporting 
requirements  documents  to  assist  us  in  our  analysis  on  why  the  JCIDS  and  its  supporting 
capabilities  documents  were  created.  We  extended  our  research  with  a  secondary 
baseline  of  the  initial  JCIDS  document  and  its  several  modifications  over  the  past  decade 
to  analyze  why  modifications  were  necessary.  An  outlying  factor  we  considered 
throughout  our  analysis  was  the  state  of  the  nation  throughout  these  modifications  and  the 
effects  on  the  MRDs/MCDs.  Fourth,  we  examined  the  culture  of  the  key  stakeholders’ 
execution  of  the  requirements  documents  and  reviewed  initiatives  to  refine  the  culture  for 
better  efficiency.  Finally,  we  focused  our  research  on  three  case  studies  of  existing 
program  offices  with  similar  ground  vehicle  platforms  that  have  undergone  different 
phases  of  the  RGP.  We  compared  and  contrasted  their  requirements  documents  to 
identify  strengths  and  weaknesses  of  requirements  documents  apparent  in  these 
acquisition  programs  based  on  the  efficiency  and  effectiveness  of  the  MRDs/MCDs. 

We  have  taken  the  data  from  these  five  distinct  qualitative  approaches  and  have 
methodically  tailored  our  analysis  towards  the  key  concepts  of  efficiency  and 
effectiveness,  change  management,  areas  of  the  BBP  initiatives,  and  the  core  ideals  of  the 
future  NSS.  By  doing  so,  we  have  been  able  to  arrive  at  our  conclusions, 
recommendations,  and  benefits,  which  we  outline  in  our  final  chapter  of  this  project. 
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A. 


ANALYSIS  CRITERIA 


1.  BETTER  BUYING  POWER 

On  September  14,  2010,  the  Honorable  Ashton  Carter,  Under  Secretary  of 
Defense  for  Acquisition,  Technology,  and  Logistics  [USD(AT&L)]  from  2009-2011, 
issued  his  guidance  known  as  Better  Buying  Power  (BBP;  USD[AT&L],  2010a).  The 
purpose  of  the  BBP  initiative  was  to  rapidly  establish  ideals  for  improved  efficiencies 
within  the  DoD,  primarily  in  the  acquisition  community,  as  the  defense  budget  was 
slowly  being  reduced.  The  USD(AT&L)’s  guidance  comprised  23  key  principles 
separated  by  five  major  areas:  (1)  target  affordability  and  control  cost  growth,  (2) 
incentivize  productivity  and  innovation  in  industry,  (3)  promote  real  competition,  (4) 
improve  tradecraft  in  services  acquisition,  and  (5)  reduce  non-productive  processes  and 
bureaucracy. 

In  the  fifth  major  area,  one  of  the  sub-principles  was  to  “reduce  the  number  of 
OSD-level  reviews  to  those  necessary  to  support  major  investment  decisions  or  to 
uncover  and  respond  to  significant  program  execution  issues”  (USD[AT&L],  2010a,  p. 
14).  BBP  acknowledged  that  there  were  areas  of  opportunities  for  better  efficiency 
within  the  DoD’s  process  for  producing  a  materiel  solution.  Carter  understood  that  the 
process  had  often  become  cumbersome  and  inefficient.  If  the  goals  of  his  BBP  initiatives 
were  to  be  achieved,  he  would  have  to  assemble  a  group  to  analyze  the  process  and, 
among  other  things,  eliminate  waste  in  requirements  generation. 

Carter  believed  that  in  order  to  prepare  his  workforce  and  industry  partners  for  the 
inevitable  reduction  in  the  defense  budget,  the  efficiency  of  the  clearly  defined 
requirements  would  be  an  essential  element  for  DoD  acquisition  operations. 

When  requirements  and  proposed  schedules  are  inconsistent,  I  will  work 
on  an  expedited  basis  with  the  Services  and  the  Joint  Staff  to  modify 
requirements  as  needed  before  granting  authority  for  the  program  to 
proceed.  In  particular,  I  will  not  grant  authority  to  release  requests  for 
proposals  until  I  am  confident  requirements  and  proposed  schedules  are 
consistent.  (USD[AT&L],  2010a,  p.  5) 


One  of  the  core  concepts  of  Better  Buying  Power  looked  internally  to  the  acquisition 

workforce  and  how  they  conducted  their  operations.  Carter  recognized  that  he  would 
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also  have  to  make  dramatic  changes  in-house  as  well.  The  acquisition  processes  would 
have  to  eliminate  redundancies  in  materiel  solutions  and  “counterproductive  overhead” 
(USD[AT&L],  2010a,  pp.  4  and  13)  if  the  DoD  was  to  continue  its  mission  and  meet  the 
needs  of  the  NS  S. 

The  defense  industry  is  also  a  key  stakeholder  within  the  DoD  RGP.  The 
relevance  of  the  defense  industry  was  apparent  when  a  representative  of  the  collective 
defense  industry  reached  out  in  a  letter  to  the  Honorable  Frank  Kendall,  the  then  newly 
appointed  and  present  USD(AT&L).  Stan  Soloway,  president  and  CEO  of  the 
Professional  Services  Council  (PSC),  wrote  to  Kendall  to  emphasize  the  defense 
industry’s  recommendations  for  consideration  during  the  development  of  the  key 
principles  of  the  next  iteration  of  BBP.  Soloway  (2012)  stated  in  his  letter, 

The  key  to  driving  quality  competitions  lies  in  the  quality  of  the 
requirements,  far  more  so  than  the  frequency  with  which  competitions  are 
held.  Thus,  it  is  important  that  Better  Buying  Power  2.0  stress  to  DoD 
components  the  importance  of  focusing  on  their  requirements  and  on 
seeking  and  rewarding  new  solutions  and  innovation,  (p.  1) 

On  November  13,  2012,  Kendall  issued  his  updated  key  guiding  principles  in 
BBP  2.0.  Kendall  still  echoed  the  same  crucial  themes  as  his  predecessor.  BBP  2.0 
comprised  36  key  principles  that  are  separated  in  seven  major  areas:  (1)  achieve 
affordable  programs,  (2)  control  costs  throughout  the  product  life  cycle,  (3)  incentivize 
productivity  and  innovation  in  industry  and  government,  (4)  eliminate  unproductive 
processes  and  bureaucracy,  (5)  promote  effective  competition,  (6)  improve  tradecraft  in 
acquisition  of  services,  and  (7)  improve  the  professionalism  of  the  total  acquisition 
workforce  (Kendall,  2012).  The  principles  complement  each  other. 

The  importance  of  requirements  was  one  theme  that  is  emphasized  in  multiple 
areas.  Four  of  BBP  2.0’s  key  principles  that  focused  on  the  requirements  generation 
process  are  (1)  eliminate  redundancy  within  warfighter  portfolios  (sub-initiative  to  the 
“control  costs  throughout  the  product  life  cycle”  initiative),  (2)  build  stronger 
partnerships  with  the  requirements  community  to  control  costs  (sub-initiative  to  the 
“control  costs  throughout  the  product  lifecycle”  initiative),  (3)  reduce  cycle  times  while 
ensuring  sound  investment  decisions  (sub-initiative  to  the  “eliminate  unproductive 
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processes  and  bureaucracy”  initiative),  and  (4)  improve  requirements  definition;  prevent 
requirements  creep  (sub-initiative  to  the  “improve  tradecraft  in  acquisition  services” 
initiative — this  principle  focuses  on  the  writing  of  performance  work  statements,  quality 
assurance  surveillance  plans,  and  performance  requirements  summaries)  (Kendall,  2012). 
Additionally,  BBP  2.0  reinforces  and  provides  further  guidance  for  information  found  in 
the  Product  Support  Manager  (PSM)  Guidebook  (Assistant  Secretary  of  Defense  for 
Logistics  and  Materiel  Readiness  [L&MR],  2011)  to  elaborate  on  future  evolving 
strategies  of  the  DoD.  Figure  14  places  the  warfighter’s  requirements  at  the  pinnacle  of 
the  Product  Support  Strategy  Process  Model. 
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Support  Management 
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Implement  & 
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Business  Case 
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Figure  14.  DoD  Product  Support  Strategy  Process  Model  (From  Assistant  Secretary  of 

Defense  [  L&MR],  2011,  p.  34) 


It  is  vital  that  requirements  are  well  defined  in  order  to  support  future  initiatives  that 
affect  the  development  of  materiel  solutions. 
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a. 


Efficiency  vs.  Effectiveness 


Efficiency  and  effectiveness  are  often  misconstrued  as  similar  means  of 
measurement.  However,  they  are  vastly  different.  An  example  of  this  comes  from  a 
battlefield  scenario.  For  example,  infantry  soldiers  are  maneuvering  across  a  danger  area, 
preparing  to  assault  on  the  main  objective.  Their  supporting  60-mm  mortar  team  has 
trained  to  quickly  fire  their  60-mm  rounds  accurately  with  a  high  rate  of  speed.  The 
mortar  team’s  purpose  during  this  mission  is  to  destroy  hunkers  surrounding  the  primary 
objective  and  facilitate  the  infantry’s  mission  to  destroy  the  main  objective.  The  mortar 
team  hits  the  bunkers  with  superior  accuracy  while  utilizing  a  minimum  of  60-mm  mortar 
rounds  to  zero  in  on  their  targets.  However,  these  bunkers  are  constructed  very  well  with 
reinforced  cover.  The  enemy  in  the  bunkers  continues  to  lay  down  a  strong  base  of  fire, 
pinning  the  infantry  soldiers  down  and  denying  the  main  assault.  The  mortar  team  is 
efficient  in  its  execution  of  its  operations,  but  it  is  not  effective  in  accomplishing  its 
mission  to  destroy  the  bunkers. 

This  cannot  be  assessed  by  looking  at  individual  components  or  teams 
involved  in  the  mission.  Both  the  mortar  teams  and  each  infantry  squad  must  contribute 
to  the  mission  as  key  stakeholders  to  be  effective.  The  lack  of  effectiveness  is  based  on 
whether  all  stakeholders  are  able  to  efficiently  conduct  their  roles  to  meet  the  overall 
mission  success,  intent,  and  end  state.  A  high  level  of  efficiency  equates  to  achieving  the 
maximum  outcome  while  utilizing  the  minimum  resources.  The  more  the  mortar  team 
executes  their  roles  correctly  during  the  operation,  the  higher  their  efficiency.  A  high 
level  of  effectiveness  is  seen  by  the  outcome  of  the  mortar  team’s  mission.  The  more 
bunkers  that  are  destroyed,  the  more  the  mortar  team  is  effective.  Ultimately,  the  mortar 
team  wants  not  only  to  execute  their  mission  with  accuracy,  precision,  and  speed,  but  also 
to  successfully  accomplish  their  mission  and  allow  the  infantry  soldiers  to  maneuver  onto 
the  main  objective. 

Figure  15  depicts  our  baseline  chart  for  efficiency  and  effectiveness  of 
MRDs/MCDs.  The  efficiency  axis  identifies  low  efficiency  as  simply  “Doing  Things.” 
We  apply  that  to  the  documents  that  allow  the  program  offices  in  this  project  to  do  things. 

High  efficiency  then  is  “Doing  Things  Right.”  We  apply  that  to  the  MRDs/MCDs,  which 
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allow  the  program  office  to  do  things  right.  Additionally,  low  effectiveness  is  also 
“Doing  Things.”  We  apply  that  to  program  offices  doing  things  to  produce  a  materiel 
solution.  High  effectiveness  is  “Doing  the  Right  Things.”  We  apply  that  to  the 
MRDs/MCDs,  which  facilitate  program  offices’  ability  to  do  the  right  things.  Hence, 
maximum  efficiency  and  effectiveness  is  “Doing  the  Right  Things  Right.”  Figure  15  is 
the  basis  of  the  model  that  we  use  to  identify  how  well  the  documents  allowed  to  the 
program  offices  use  the  least  amount  of  resources  required  to  produce  the  best  materiel 
solution  for  the  warfighter. 


Doing  the  Right  Things 

Doing  the  Right  Things 
Right 

Doing  Things 

Doing  Things  Right 

Efficiency  H,Rh 


Figure  15.  Efficiency  and  Effectiveness  Model  (From  Griiter  &  Boerendans,  2013) 


The  following  five  key  initiatives  of  BBP  2.0  are  what  we  focused  our 
analysis  on,  per  the  BBP  2.0  memorandum  (Kendall,  2012).  We  separated  these  five 
initiatives  linked  to  the  requirements  documents  into  two  categories,  the  initiatives  that 
supported  efficiency  and  those  that  supported  effectiveness. 

b.  Efficiency  Initiatives 

In  our  analysis,  efficiency  is  qualitative.  Our  study  focuses  on  SMEs’ 
opinions  on  how  well  the  requirements  documents  facilitated  efficiencies  in  their  mission 
to  use  the  least  amount  of  resources  to  produce  a  materiel  solution  with  minimum 
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modifications.  Additionally,  efficiency  is  based  on  the  stakeholders  and  the  individuals 
who  were  directly  involved  in  the  execution  of  the  MRDs/MCDs.  We  measured 
efficiency  against  two  initiatives.  The  first  measures  the  efficiency  of  stakeholders’ 
collaboration  to  produce  the  documents  and  maximize  buy-in.  This  aspect  deals  with 
efforts  between  the  program  office  and  the  CBTDEV  to  work  towards  establishing 
acceptable  trade-offs  for  requirements.  The  second  factor  deals  with  cycle  time  from 
paper  to  product.  Time  is  an  essential  factor  to  efficiency  as  it  focuses  on  the  program’s 
time  to  execute  their  mission  based  off  the  MRDs/MCDs. 

We  measure  efficiency  based  on  two  BPP  initiatives:  (1)  Build  Stronger 
Partnerships  With  The  Requirements  Community  to  Controls  Costs  and  (2)  Reduce  Cycle 
Times  While  Ensuring  Sound  Investment  Decisions. 

(1)  Build  Stronger  Partnerships  With  The  Requirements 
Community  to  Control  Costs. 

This  is  an  area  of  continuing  emphasis  in  which  good  progress  has  been 
made,  but  more  needs  to  be  done.  More  than  anything  else,  requirements 
drive  costs.  The  requirements  and  acquisition  communities  must  cooperate 
more  closely  and  continuously  to  ensure  that  requirements  are  technically 
achievable  and  affordable  so  that  operational  and  Service  leadership  can 
make  informed  decisions  about  the  costs  associated  with  varying  levels  of 
performance.  For  Major  Programs,  the  DAE  is  working  closely  with  the 
VCJCS  and  the  JROC,  and  each  Service  has  taken  steps  in  the  right 
direction.  However,  more  needs  to  be  done  to  ensure  well  informed 
requirements  decisions  that  balance  cost  and  performance  throughout 
product  lifecycles.  (Kendall,  2010,  p.  3) 

This  initiative  emphasizes  the  importance  of  the  collaboration  of 
those  key  stakeholders  involved  with  requirements.  Building  stronger  partnerships  with 
those  who  define  requirements  allows  the  program  offices  to  minimize  the  resources 
needed  to  execute  their  operations.  It  is  essential  that  the  program  offices  are  aligned 
with  other  external  stakeholders  to  fully  understand  and  clearly  define  requirements  to 
execute  their  mission  with  the  utmost  efficiency. 

(2)  Reduce  Cycle  Times  While  Ensuring  Sound  Investment 

Decisions. 
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This  initiative  will  assess  the  root  causes  for  long  product  cycle  times, 
particularly  long  development  cycles,  with  the  goal  of  significantly 
reducing  the  amount  of  time,  and  therefore  cost,  it  takes  to  bring  a  product 
from  concept  to  fielding.  A  full  range  of  factors — oversight  activities, 
funding  stability,  contracting  lead  time,  requirements  processes,  technical 
complexity,  use  of  risk  reduction  activities,  and  testing  requirements — will 
be  considered  as  possible  contributing  factors.  (Kendall,  2010,  pp.  4-5) 

This  initiative  also  is  inclusive  to  the  MRDs/MCDs.  We  analyzed 
the  documents  to  understand  the  effects  of  their  impact  on  cycle  time.  Efficient 
MRDs/MCDs  would  allow  cycle  time  to  either  decrease  or  remain  constant.  Clarity  and 
specificity  allow  requirements  to  be  thoroughly  understood  and  efficiently  guide  the 
program  office  to  manage  the  development  of  the  materiel  solution.  Furthermore, 
MRDs/MCDs  with  a  low  efficiency  can  result  in  increase  of  a  program’s  cost,  schedule, 
and  performance  due  to  misinterpretation  of  the  requirements.  For  example,  if  a  CDD  is 
not  clearly  understood  by  the  program  office  because  of  lack  of  collaboration,  the 
program  office  may  dedicate  resources  towards  a  materiel  solution  that  does  not  fill  the 
capability  gap,  thus,  resulting  in  a  decrease  in  efficiency. 

c.  Effectiveness  Initiatives 

In  addition,  the  warfighter  requires  materiel  solutions  to  effectively 
overcome  their  capability  gaps.  Three  measures  were  used  to  analyze  the  effectiveness  of 
the  MRDs/MCDs  in  the  creation  and  production  of  a  materiel  solution.  For  the  first 
measurement,  we  evaluated  the  effectiveness  of  the  documents  by  identifying  whether 
redundancy  has  been  created  within  the  Army’s  portfolio.  The  second  measurement  was 
based  on  the  quantity  of  modifications  required  within  the  program  after  the 
MRDs/MCDs.  The  final  measurement  for  effectiveness  was  establishing  stronger 
qualification  requirements  for  those  involved  with  the  execution  of  the  MRDs/MCDs. 
This  provided  the  ability  to  measure  the  level  of  effectiveness  for  MRDs/MCDs  that 
allow  key  stakeholders  to  operate  within  their  own  organizations  and  successfully 
complete  their  respective  missions. 


72 


Effectiveness  is  represented  by  two  other  initiatives:  (1)  Eliminate 
Redundancy  within  Warfighter  Portfolios  and  (2)  Improve  Requirements  Definition; 
Prevent  Requirements  Creep. 

(1)  Eliminate  Redundancy  Within  Warfighter  Portfolios. 

Duplicate  or  redundant  efforts  occur  at  the  program  level  due  to 
constraints  in  the  component  requirements  process.  The  Department  will 
identify  synergies  for  existing  and  planned  programs  across  the  Services 
during  MDD  reviews,  Program  Budget  Reviews  (PB  build),  and  across  all 
levels  of  the  buy.  (Kendall,  2012,  p.  2) 

This  initiative  is  our  first  measure  of  effectiveness.  A  program 
office  is  able  to  produce  a  more  effective  product  if  the  warfighter  portfolio  is  reduced  to 
those  capabilities  the  warfighter  needs  to  fill  the  identified  capability  gaps.  This  requires 
clearly  defined  requirements  in  MRDs/MCDs.  The  MRDs/MCDS  are  then  effective 
when  the  program  office  prevents  programs  from  developing  systems  with  similar 
capabilities. 

Mr.  Robert  L  Gustavus,  a  certified  public  accountant  and  faculty 
member  of  the  Defense  Acquisition  University  (DAU),  elaborates  further  in  DAU  class 
entitled,  “Better  Buying  Power:  Guidance  for  Obtaining  Greater  Efficiency  and 
Productivity  in  Defense  Spending.”  Gustavus  explains  that  this  initiative  exists  because 
the  future  budget  of  the  DoD  cannot  effectively  support  capabilities  that  are  duplicated. 
The  DoD  must  minimize  redundancy  with  the  warfighter  portfolio  to  maximize  cost- 
effectiveness.  Gustavus  outlines  that  by  eliminating  unnecessary  capabilities  that  are 
duplicative,  acquisition  and  procurement  costs  will  reduce  by  30%  of  total  cost,  and  70% 
of  the  total  costs  of  sustainment.  Furthermore,  he  elaborates  that  this  must  be  conducted, 
managed,  and  tracked  across  all  Services.  Lastly,  Gustavus  recognizes  that  this  is  not  a 
simple  process,  however  it  is  key  to  success  in  effectively  implementing  this  initiative 
(Gustavus,  2012,  slides  33  and  34). 

An  example  illustrating  his  explanation  is  the  M-ATVs  KPP 
capabilities  outlined  in  the  CPD.  These  programs  expected  C4ISR  performance  to 
support  both  interoperability  and  open  architecture  for  existing  products.  However,  the 
M-TAV  was  integrated  with  service  specific  jammers  and  internal  communication 
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technologies.  By  the  capabilities  not  clearly  defined  in  the  MCD,  PM  M-ATV  was 
required  to  engineer  multiple  capabilities  integration.  This  created  to  separate  platform 
configurations.  A  base  model  M-ATV,  after  it  received  CONUS  integration,  could  not  be 
fielded  to  the  warfighters,  but  had  to  be  fielded  to  a  service  specific  warfighter  due  the 
redundancies  within  the  platform’s  portfolio.  A  USMC  configured  M-ATV  could  not  be 
fielded  to  Army  units.  This  also  added  increase  cost  and  planning  to  deliver  service 
specific  M-ATVs  to  the  best  location. 

Thus,  MRDs/MCDs  that  clearly  define  requirements  minimize 
redundancies  in  a  final  materiel  solution  and  allows  program  offices  to  define  their  goals 
necessary  to  meet  the  expectations  of  the  capabilities  gap,  and  be  more  effective  in  the 
finalized  materiel  solution. 

(2)  Improve  Requirements  Definition;  Prevent  Requirements 

Creep. 

This  initiative  is  located  under  the  heading  “Improve  Tradecraft  in 
Acquisition  Services”  (Kendall,  2010).  This  point  focuses  on  the  writing  of  performance 
work  statements,  quality  assurance  surveillance  plans  and  performance  requirements 
summaries  (Kendall,  2010).  However,  in  Mr.  Kendall’s  memorandum  in  2010,  subject: 
Improving  DoD  Acquisition  Requirements  Development,  he  states  this  he  has  put 
together  a  panel  to  review  the  “...progress  made  by  the  Department  of  Defense  (DoD)  to 
eliminate  areas  of  vulnerability...”  (USD[AT&L],  2010b,  p.  1).  He  then  explains  what 
the  panel  determined  from  these  reviews: 

The  need  to  address  requirements  development,  which  has  been  identified 
as  a  weakness  in  the  Department  and  has  led  to  cost  and  schedule  overruns 
on  many  programs.  Requirements  development  is  paramount  to 
successful  acquisition  outcomes.  Properly  developed  requirements 
enhance  competition,  ensure  sound  business  strategies,  provide  the  basis 
for  realistic  Government  estimates,  mitigate  requirements  creep,  and  help 
enable  the  Department  meet  critical  acquisition  timelines.  (USD[AT&L], 

2010b,  p.  1) 

While  this  specific  initiative  may  be  focused  on  the  domain  of 
acquiring  services  such  as  LOGCAP  or  analytical  support  services,  the  initiatives  still  is 

linked  to  Mr.  Kendall’s  emphasis  the  effects  of  requirements  creep  on  producing  a 
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materiel  solution.  We  analyzed  this  initiative  to  study  the  concept  that  if  MRDs/MCDs 
are  not  written  effectively  enough  to  consider  and  project  future  capabilities,  an  increase 
of  requirements  creep  will  ultimately  decrease  the  effectiveness  of  MRDs/MCDs. 

The  Department  will  continue  this  initiative.  We  have  developed  tools  to 
assist  users  in  writing  Performance  Work  Statements,  Quality  Assurance  Surveillance 
Plans,  and  Performance  Requirements  Summaries,  and  we  will  increase  the  training  of 
cross-functional  teams  involved  in  formulating  requirements  for  service  contracts. 
(Kendall,  2010,  p.  6) 

This  statement  reinforces  Kendall’s  emphasis  on  developing  quality 
requirements  for  all  stakeholders.  This  initiative  provides  guidance  to  continue  due 
diligence  to  produce  clear  requirements  within  the  MRDs/MCDs,  and  to  prevent 
programs  from  continually  executing  capability  insertions.  Programs  with  expanding 
requirements  increase  the  risk  of  issues  arising  later  on  in  their  acquisition  life  cycle, 
which  inevitably  leads  to  increased  program  cost,  schedule,  and  performance.  Even 
though  this  BBP  initiative  came  after  many  of  the  programs,  we  analyzed  the  concepts  of 
BBP  2.0  in  our  case  study  to  understand  how  well  these  programs  adhered  to  this 
initiative. 

We  analyzed  this  initiative  and  focused  on  the  aspect  of  preventing 
requirements  creep.  Requirements  creep  takes  away  from  the  effectiveness  of  approved 
MRDs/MCDs.  Approved  MRDs/MCDs  generate  the  forward  momentum  to  begin 
development  of  a  materiel  solution.  Additional  requirements  outside  of  the  scope  of  the 
MRDs/MCDs  creates  requirements  creep,  which  impacts  the  program  through  the  means 
of  engineering  change  proposals  (ECP)  and  modifications  to  the  platform.  Additionally, 
MRDs/MCDs  can  mitigate  requirements  creep  by  identifying  requirements  and 
capabilities  up  front.  This  mitigation  may  occur  by  conducting  analysis  in  the  form  of 
past  DOTMLS  and  DOTMLP-F,  or  the  present  DOTmLTF-P.  Effective  analysis 
provides  the  means  to  identify  and  address  needs  and  future  capabilities,  such  as 
interoperability  and  open  architecture,  to  be  fully  considered  in  MRDs/MCDs.  Thus,  the 
more  requirements  added  outside  of  the  scope  of  the  MRDs/MCDs,  the  less  these 
documents  are  effective. 
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Based  on  these  initiatives,  we  rate  an  alternative  as  “poor,”  “average,  or 
“excellent”  based  on  comments  received  from  SMEs  in  relation  to  the  definitions  of  each 
BPP  initiative  during  our  interviews.  A  poor  rating  indicates  the  requirement  documents 
did  not  sufficiently  support  the  program  office  in  meeting  the  intent  of  the  initiative. 
Average  means  that  the  requirements  documents  had  minimal  impacts  on  the  program 
office  meeting  the  intent  of  their  initiative.  Finally,  an  excellent  rating  was  assigned  to 
requirements  documents  that  did  not  impact  a  program’s  performance  in  meeting  the 
BBP  initiative. 

Figure  16  is  the  scorecard  that  we  used  in  each  of  our  case  studies.  We 
assessed  each  wheeled  vehicle  platform’s  MRDs/MCDs  in  relation  to  efficiency  and 
effectiveness.  Eater,  Figure  16  is  combined  with  Figure  18  to  provide  our  analysis  results. 


BBP  2.0  Principles  and  Initiatives 

rmrnmTT  -  Rating  | 

Poor 

1  Average  1 

1  Excellent  1 

I  Efficiency  Initiatives  ! 

(1)  Build  Stronger  Partnerships  With  The 

Requirements  Community  To  Control  Costs 

(2)  Reduce  Cycle  Times  While  Ensuring  Sound 
Investment  Decisions 

|  Effectiveness  Initiatives  |j 

(1)  Eliminate  Redundancy  Within  Warfighter 
Portfolios 

(2)  Improve  Requirements  Definition  And 

Prevent  Requirements  Creep 

Figure  16.  BBP  2.0  Scorecard 

In  our  research,  we  conducted  interviews  with  stakeholders  from  three 
program  offices  as  well  as  others  within  the  acquisition  community.  We  tailored  our 
questions  to  the  efficiency  and  effectiveness  of  MRDs/MCDs  linked  to  BBP  2.0.  Even 
though  these  programs  were  initiated  prior  to  the  BBP  2.0,  the  SMEs  provided  their 
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insights  on  how  they  felt  their  documents  adhered  to  these  initiatives.  Additionally,  they 
provided  opinions  on  the  effects  of  the  documents  in  regards  to  efficiency  and 
effectiveness. 

2.  CHANGE:  EVOLUTIONARY  VERSUS  REVOLUTIONARY 

Dr.  H.  James  Harrington,  a  business  consultant  for  quality  improvement  and 
change  management  within  organizations,  described  the  ability  to  improve  quality  and  to 
reach  change: 

[Measurement  is  the  first  step  that  leads  to  control,  and,  eventually,  to 
improvement.  If  you  can’t  measure  something,  you  can't  understand  it.  If 
you  can’t  understand  it,  you  can’t  control  it.  If  you  can’t  control  it,  you 
can’t  improve  it.  (Harrington  &  McNellis,  2006) 

Change  is  absolutely  imperative  to  process  improvement  and  improvement  of  the 
MRDs/MCDs  that  support  the  RGP.  However,  change  is  often  a  very  difficult  task, 
especially  in  well-established  organizations  with  developed  processes,  history,  and 
traditions,  like  the  DoD.  Constructive  change  comes  from  the  recognition  of  the  current 
state  of  an  organization  or  process,  the  necessity  to  alter  that  current  state  for 
improvement  and  better  efficiencies,  and  implementation  of  appropriate  modifications  to 
better  the  current  state.  Change  management  is  the  art  of  planning  a  strategy  for  change, 
effectively  employing  that  strategy,  and  sustaining  the  change  until  it  becomes  the  new 
current  state.  Additionally,  change  may  also  come  in  two  different  forms,  evolutionary  or 
revolutionary. 

The  two  changes  evaluated  in  our  study  are  evolutionary  change  and 
revolutionary  change  (Cunningham  &  Hamey,  2012).  Evolutionary  change  is  reactive 
change.  It  is  the  continual  adjustment  or  modification  to  the  existing  process. 
Evolutionary  change  is  directed  when  there  is  the  desire  to  be  more  efficient.  Since  the 
establishment  of  the  JCIDS  in  2003,  CJCSI  3170.01  has  undergone  eight  evolutionary 
modifications  to  improve  the  JCIDS  process  and  its  associated  requirements  documents. 
This  is  seen  in  CJCSI  3130.01  versions  C-H. 

Alternatively,  revolutionary  change  is  proactive  change  that  is  necessary  to  adapt 

to  a  new  environment  once  the  current  reality  has  changed.  The  switch  from  the  RGS  to 
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the  JCIDS  was  a  revolutionary  change  when  SECDEF  Donald  Rumsfeld  identified  that  a 
new  method  was  needed  in  order  to  meet  the  current  challenges  of  the  warfighter  as  well 
as  the  future  challenges  presented  in  the  NSS.  Revolutionary  change  often  encompasses 
an  overhaul  in  strategy,  structure,  processes,  and  culture  (Cummings  &  Worley,  2008). 

We  have  analyzed  the  efficiency  and  effectiveness  of  requirements  documents, 
not  the  efficiency  and  effectiveness  of  the  vehicle  platforms  themselves,  within  their 
respective  RGP.  We  have  identified  whether  the  MRDs/MCDs  efficiently  served  their 
purposes  during  the  RGS  and  whether  the  JCIDS  documents  are  currently  serving  their 
purposes.  We  implemented  consideration  on  why  the  RGS  MRDs  lost  their  effectiveness 
and  were  replaced  by  the  JCIDS  MCDs.  Additionally,  we  have  tried  to  determine 
whether  the  current  JCIDS  requirements  documents  have  reached  the  end  of  their 
effectiveness  and  whether  new  revolutionary  change  is  needed.  We  have  accomplished 
this  by  reviewing  the  MRDs/MCDs  from  three  vehicle  program  offices  and  by 
conducting  interviews  with  the  SMEs  who  were  directly  involved  with  the  execution 
documents  for  each  platform. 

In  the  chapter  conclusion  and  from  each  of  the  individual  case  studies,  we 
analyzed  the  type  of  change  that  may  be  needed  based  on  the  MRDs/MCDs’  placement 
on  the  efficiency  and  effectiveness  model.  Figure  17  depicts  the  integration  of  change 
with  the  previous  efficiency  and  effectiveness  model  shown  in  Figure  15. 
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Figure  17.  Efficiency  and  Effectiveness  Linkage  to  Evolutionary  and  Revolutionary  Change 

Linkage  (After  Griiter  &  Boerendans,  2013) 

The  enlarged  block  arrows  show  that  a  need  for  evolutionary  change  increases  as 
efficiency  decreases.  Conversely,  the  enlarged,  block  arrows  show  that  a  need  for 
revolutionary  change  increases  as  effectiveness  decreases.  The  less  efficient  the 
MRDs/MCDs  were  for  a  program  office  to  execute  their  mission  to  produce  a  materiel 
solution,  the  greater  the  need  for  evolutionary  change.  On  the  other  hand,  as  RGS 
MRDs’  effectiveness  decreases,  the  more  the  need  for  revolutionary  change  increases  to 
create  the  JCIDS  MCDs.  Therefore,  we  analyzed  the  reasons  that  both  MRDs  and  MCDs 
have  evolved,  as  well  as  the  reasons  MRDs  were  revolutionized  into  MCDs. 

3.  RATING  SCHEME 

The  final  compilation  of  our  analysis  is  with  the  efficiency  and  effectiveness 
model  and  the  integration  of  a  rating  scheme.  These  ratings  are  tied  into  our  concepts  of 
efficiency  and  effectiveness,  evolutionary  and  revolutionary  change  integration,  and 
Better  Buying  Power  2.0  initiatives.  Figure  18,  below,  is  the  model  we  used  to  evaluate 
three  vehicle  programs  in  two  different  acquisition  processes. 
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Figure  18.  Efficiency  and  Effectiveness,  Revolutionary  and  Evolutionary  Change,  and 

Rating  Model  (After  Griiter  &  Boerendans,  2013) 


We  examined  the  MRDs/MCDs  of  the  HMMWV,  M-ATV,  and  JLTV  and  how 
well  they  rank  in  terms  of  efficiency  and  effectiveness  according  to  BPP  initiatives.  For 
efficiency,  we  assign  a  qualitative  measure  based  on  SME  responses  across  the  two  BBP 
2.0  initiatives  noted  above.  For  effectiveness,  we  assign  a  qualitative  measure  based  on 
SME  responses  to  the  three  BPP  initiatives  mentioned  earlier.  Figure  19  shows  the 
criteria  we  use  to  assess  efficiency  and  effectiveness. 


BBP  2.0  Principles  and  Initiatives 
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Figure  19.  Overall  Rating  Model  (After  Griiter  &  Boerendans,  2013) 
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B.  CASE  STUDIES 


1.  High  Mobility  Multipurpose  Wheeled  Vehicle  (HMMWV) 

An  image  of  the  Ml  151  model  of  the  HMMWV  FoV  is  shown  in  Figure  20 

below. 


Figure  20.  Ml  151  HMMWV  (From  Banyai-Riepl,  n.d.) 


a.  Mission 

“To  develop,  acquire,  produce,  field,  and  sustain  safe,  reliable,  effective 
and  supportable  light  tactical  vehicles  for  the  joint  war  fighting  community”  (Product 
Manager  Light  Tactical  Vehicles  [PM  LTV],  2013). 

b.  Vision 

“Providing  our  war  fighters  with  superior  and  comprehensive  program 
management  services,  world  class  light  tactical  vehicles,  and  responsive  life  cycle 
support”  (PM  LTV,  2013). 
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c. 


Focus 


“Close  capability  gaps,  while  increasing  performance  and  protection,  to 
meet  our  customer’s  needs”  (PM  LTV,  2013). 

d.  HMMWV  Background 

The  HMMWV  began  as  a  joint  Service  program  in  support  of  the  Army, 
Air  Force,  and  USMC  and  was  led  by  the  U.S.  Army  as  an  ACAT  IC  program.  The 
initial  intent  for  the  HMMWV  was  to  replace  some  of  the  family  of  tactical  vehicles  such 
as  the  M151  Jeep,  M880  and  M561  Utility  Trucks,  and  the  M792  Ambulance.  The 
HMMWV  program’s  purpose  was  to  provide  commonality  for  a  chassis  to  minimize 
future  life-cycle  sustainment  costs. 

The  HMMWV  program  took  five  years  from  MNS  approval  to  full-rate 
production,  excluding  time  required  to  draft  the  MNS.  Also  known  as  the  Joint  Mission 
Element  Needs  Statement  (JMENS),  the  MNS  for  the  HMMWV  was  approved  on  July  8, 
1980.  On  July  1,  1981,  one  year  after  the  approved  MNS,  the  Program  Office  of 
HMMWV  awarded  contracts  for  prototype  to  three  vendors:  AM  General,  General 
Dynamics,  and  Teledyne  Continental.  Prototypes  came  one  year  after  the  contracted  was 
awarded.  At  MS  C,  in  1983,  AM  General  received  the  award  for  a  multiyear  contract  to 
produce  approximately  55,000  HMMWVs.  Not  long  after,  the  requirement  increased  to 
70,000  HMMWV  for  production  and  the  cost  grew  from  $1.2  billion  to  $1.6  billion. 
Then,  an  additional  three  years  of  testing,  source  selection,  contract  award,  and  ORD 
approval  occurred  before  first  HMMWV  was  produced.  Finally,  in  the  year  2000,  all  of 
the  HMMWVs  produced  reached  the  end  of  their  project  15-year  life  cycle.  By  2001,  the 
HMMWV  fleet’s  “average  age  was  approximately  10.8  years  old”  (DAU,  2005,  p.  1). 

The  aging  HMMWV  fleet  brought  about  the  recapitalization  effort  for  the 
vehicles  that  were  approaching  the  end  of  their  life  cycle.  Recapitalization  efforts  were  a 
recognized  need  as  the  HMMWV  fleet  was  becoming  costly  in  terms  of  operation  and 
support  (O&S)  and  maintainability.  The  recapitalization  program  for  the  HMMWV 
meant  that  the  truck  would  have  to  meet  new  conditions  of  zero  hours  and  miles.  This 
would  require  a  new  engine  and  drive  train,  as  well  as  50  new  modernized  parts.  The 
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cost  estimated  by  the  PM  offices  was  $42,000  to  recapitalize  a  $48,000  truck.  The  PM 
HMMWV  did  not  find  it  cost-effective  to  recapitalize  a  HMMWV  when  it  would  cost 
$6,000  more  for  a  new  truck.  Investing  in  a  new  truck  seemed  to  make  more  sense. 
Investing  in  a  production  line  that  was  still  producing  HMMWVs,  versus  competing  a 
new  contract  for  tear-down  and  reassembly  of  an  old  HMMWV,  was  the  preferred 
approach  (DAU,  2005).  Investment  in  the  recapitalization  program  was  also  desired  from 
the  influence  of  generated  ONSs  to  support  the  warfighter  in  the  GWOT. 

In  the  beginning  of  the  GWOT,  the  threat  of  IEDs  was  increasing  in  Iraq. 
This  threat  would  later  increase  in  Afghanistan  as  well.  By  September  2003,  add-on 
armor  kits  for  HMMWVs  were  acquired  in  response  to  an  ONS  from  theater.  The 
original  ONS  request  was  for  8,400  kits.  In  July  2004,  the  ONS  requested  an  additional 
4,760  kits  to  meet  the  CENTCOM  AOR  requirement.  The  PM  HMMWV  assisted  the 
CMBDEV  in  writing  another  ORD  in  support  of  the  block  upgrades  and  new  HMMWVs 
to  their  family  of  vehicles  (FoV).  This  ORD  was  approved  by  JROC  in  September  2004. 
Even  though  the  JCIDS  had  already  been  implemented,  the  existing  approved  ORD  was 
still  valid  through  2005.  These  additional  HMMWVs  are  seen  on  the  bottom  row  of 
Figure  21.  In  January  2005,  the  first  five  add-on  armor  kits  were  delivered  to  Iraq,  and 
one  month  later,  the  AOR  commander  implemented  a  policy  that  no  HMMWVs  were 
allowed  to  leave  a  forward  operating  base  without  an  add-on  armor  kit  installed  on  the 
vehicle  (A.  H.  Ha,  personal  communication,  April  13,  2013). 
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M966  HMMWV  TOW  M1025  HMMWV  M998  HMMWV  CARGO 

CARRIER  ARMAMENT  CARRIER  TROOP  CARRIER  SHELTER  CARRIER 


M1037  HMMWV 


M1038  HMMWV  M1097  HMMWV  CARGO 

SHELTER  CARRIER  CARRIER 


M1097  HMMWV 
SHELTER  CARRIER 


Ml  114  UP-ARMORED 
HMMWV  (UAH) 


M1097R1  HMMWV 
RECAP 


Ml  151  ENHANCED  M1152  ENHANCED  M1165  ENHANCED  M1167  ENHANCED 

ARMAMENT  CARRIER  CARGO/TROOP  COMMAND  AND  TOW  CARRIER 

CARRIER  CONTROL  CARRIER 


M1035  HMMWV 
AMBULANCE  2  LITTER 


M996  HMMWV 
AMBULANCE  2  LITTER 


M997  HMMWV 
AMBULANCE  4  LITTER 


M1113  HMMWV 
EXPANDED  CAPACITY 
VEHICLE  (ECV) 


Figure  21.  HMMWV  Family  of  Vehicles  (From  Bassett,  2011,  p.  6) 


To  place  this  program  in  perspective,  the  HMMWV  is  a  materiel  solution  that 
existed  through  the  RGS,  and  its  life  cycle  continued  through  the  inception  of  and 
modifications  to  the  JCIDS.  Although  the  JCIDS  was  enacted  in  June  2003,  as  per 
CJCSI  3170.01C  (CJCS,  2003), 

[djocuments  that  were  approved  under  the  Requirements  Generation 
System  remain  valid,  except  as  detailed  below: 

(2)  Mission  Need  Statements  (MNSs)  that  have  initiated  staffing  in  the 
JCPAT  will  continue  through  the  normal  staffing  process.  No  new  MNSs 
will  be  accepted  for  staffing.  Initial  Capabilities  Documents  (ICD), 
developed  in  accordance  with  this  instruction,  will  be  used  instead. 
Programs  that  have  already  completed  acquisition  Milestone  A  or  beyond 
are  not  required  to  update  the  MNS  with  an  ICD.  No  MNS  greater  than  2 
years  old  will  be  used  to  support  a  Milestone  A  (or  programs  proceeding 
directly  to  Milestone  B  or  C)  acquisition  decision. 

(3)  Operational  Requirements  Documents  (ORD)  will  be  accepted  for 
Joint  Staff  review  for  a  period  of  6  months  after  approval  of  this 
document.  After  the  6-month  period,  only  ORD  updates/annexes,  CDDs 
and  CPDs  developed  in  accordance  with  this  instruction  will  be  accepted. 

A  validated  and  approved  ORD,  developed  under  a  previous  version  of 
this  instruction,  may  be  used  to  support  a  Milestone  B  or  C  decision  in  lieu 
of  a  CDD  or  CPD  for  up  to  2  years  following  approval  of  this  instruction. 

(P-3) 
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The  PM  HMMWV  continued  to  use  RGS  documents  to  support  their  program  even  after 
the  JCIDS  was  enacted.  Up-armored  HMMWV  were  an  urgent  and  compelling  need  by 
2004  due  the  growing  threat  of  the  GWOT.  The  following  requirements  documents  have 
been  used  to  support  our  analysis:  JMENS,  ORD-Initial,  and  ORD-Revised. 

e.  HMMWV  Better  Buying  Power  2.0  Efficiency  Analysis 

(1)  Build  Stronger  Partnerships  With  the  Requirements 
Community  to  Control  Costs. 

Rating:  Poor 

Initial  stages  of  the  HMMWV  program  could  have  benefited  from 
stronger  communications  between  PM  HMMWV  and  the  CBTDEV  to  define  the 
requirements  in  the  MRDs.  Requirements  outlined  in  the  initial  HMMWV  MRDs  were 
mission-focused  to  serve  the  warfighter  in  a  tactical  capacity.  There  was  minimum 
consideration  for  cost. 

The  requirements  generation  process  for  the  HMMWV  were  [s/c] 
conducted  well  before  there  was  any  cost  consideration  by  the  user 
community.  The  requirements  were  transmitted  to  the  PM  with  the 
performance  level  the  user  specified.  The  PM  was  nearly  solely 
responsible  for  cost  control  and  only  rarely  went  back  to  the  user  for 
changes  in  performance  requirements  to  achieve  any  affordability  goals. 
Funding  levels  typically  dictated  procurement  quantities,  not  design 
decisions.  (B.  Naegle,  personal  communication,  April  26,  2013) 

A  stronger  partnership  between  the  program  office  and  the 
CBTDEV  would  have  allowed  for  more  trade-offs  to  have  more  efficiently  executed  their 
mission  to  serve  the  warfighter.  Later,  in  the  program’s  life  cycle,  during  the  GWOT,  a 
communication  system  was  established  to  help  develop  efficiencies. 

Additionally,  PM  HMMWV  wanted  to  collaborate  with  a  user 

representative  from  the  combat  arms  community  to  ensure  they  were  meeting  the 

expectations  of  the  warfighter.  However,  “the  TRADOC  system  manager  (TSM)  for  the 

HMMWV  was  an  0-6,  Army  branched  Quartermaster  by  trade  and  still  serving  the 

Quartermaster  Branch”  (B.  Naegle,  personal  communication,  April  26,  2013).  PM 

HMMWV  recognized  the  importance  of  the  TSM  to  clearly  ensure  that  the  CBTDEV 
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authored  effective  MRDs.  The  TSM  had  a  key  role  in  the  requirement  generation  and 
refinement  process. 

The  TSMs  represented  all  major  weapon  and  materiel  systems  in 
development  and  functioned  with  power  and  authority  comparable  to 
those  of  the  program  and  project  managers  within  the  U.S.  Army  Materiel 
Command  (AMC).  (Harris  &  Robertson,  2011,  p.  67) 

TSMs  served  as  user  advocates — the  “voice”  of  the  warfighter — and 
worked  in  complement  with  the  system  developers.  (Harris  &  Robertson, 

2011,  p.  67) 


The  PM  HMMWV  found  it  very  difficult  to  produce  the  vehicle  to 
satisfy  the  requirements  documents.  Requirements  documents  must  have  full  attention  by 
all  stakeholders  throughout  each  step  of  the  RGS  process  in  order  to  be  efficient. 

PM  HMMWV  reassessed  what  they  believed  needed  to  take  place 
to  establish  collaboration  and  took  the  initiative  to  seek  out  feedback  from  the  combat 
arms  branches.  This  became  even  more  prevalent  as  the  ONS  came  down  to  produce  an 
up-armored  HMMWV  in  support  of  Kosovo  and  eventually  Iraq  and  Afghanistan.  The 
original  ORD  called  for  an  up-armored  platform.  However,  the  ONS  brought  a 
requirement  to  increase  survivability  for  up-armored  HMMWVs  that  was  specifically 
shaped  towards  the  ongoing  combat  operations  in  Iraq  and  Afghanistan.  “Capabilities 
delivered  in  response  to  ONS  documents  that  required  significant  research  and 
development  efforts  included  armor  solutions,  such  as  body  armor  and  HMMWV 
fragmentation  kits...”  (Office  of  the  USD[AT&L],  2009,  p.  13).  The  PM  office’s  intent 
was  to  get  the  right  solution  based  on  the  users  that  would  utilize  the  vehicle  for  combat 
operations. 

We  ramped  up  the  production  line  for  an  up  armor  HMMWV.  We  had  to 
design,  develop,  test,  modify  and  field  an  add-on  armor  kit,  and  then  just  a 
series  of  upgrades.  It’s  been  a  case  of  where  you  get  a  basic  capability  to 
the  field  as  quickly  as  possible,  have  some  type  of  feedback  mechanism 
forward  in  the  field,  you  know,  once  the  soldiers  tell  you  what  works  and 
what  doesn’t  and  the  threat  continues  to  evolve  and  you’ve  got  to  have  a 
system  to  set  up  here  and  upgrade.  (K.  Peterson,  personal  communication, 
October  23,  2012) 
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Nonetheless,  even  feedback  from  the  mounted  combat  arms  community  to  the  PM  office 
was  limited.  At  the  time,  there  seemed  to  be  more  focus  on  their  primary  platforms,  such 
as  the  Bradley  fighting  vehicle  and  Abrams  tanks,  and  preparing  for  combat. 

As  a  result,  the  HMMWVs  produced  would  not  meet  the  needs  of  combat  arms 
personnel.  In  Kosovo,  there  were  many  places  mounted  warfighters  could  not  take  their 
Bradley  fighting  vehicles  and  tanks.  They  would  have  had  to  rely  on  the  lighter  and  more 
maneuverable  platform  of  the  HMMWV  if  they  wanted  to  successfully  traverse  the 
terrain.  However,  they  were  not  satisfied  with  the  performance  of  the  HMMWV  and 
requested  additional  modifications  and  capabilities.  Years  later,  this  predicament 
surfaced  again  in  both  Afghanistan  and  Iraq  during  the  GWOT.  These  capabilities  could 
have  been  better  projected  had  the  collaboration  between  the  right  stakeholders  occurred 
with  the  generation  of  the  requirements.  As  a  result,  the  HMMWV ’s  cost  increased 
throughout  its  life  cycle  to  accommodate  these  many  modifications  and  retrofits  (B. 
Naegle,  personal  communication,  April  26,  2013). 

(2)  Reduce  Cycle  Times  While  Ensuring  Sound  Investment 

Decisions. 

Rating:  Average 

In  the  1980s,  there  was  no  urgent  need  for  materiel  solutions. 
Pressures  to  fulfill  urgent  and  compelling  needs  to  meet  the  demands  of  war  were  not 
great.  Thus,  there  was  not  a  great  deal  of  pressure  to  rapidly  produce  a  materiel  solution. 
This  did  afford  the  program  the  opportunity  to  execute  the  materiel  solution  in  a  steady 
state  environment.  The  MRDs  provided  clear  requirements  to  the  program  office  to 
identify  the  ability  to  use  a  non-developmental  item  for  the  materiel  solution.  “HMMWV 
was  a  non-developmental  item  (NDI)  procurement,  leveraging  as  much  automotive 
maturity  as  possible.  This  made  it  possible  to  truncate  the  process,  with  parts  of  phases 
and  events  eliminated,  speeding  the  development  process”  (B.  Naegle,  personal 
communication,  April  26,  2013).  Non-developmental  items  yield  the  opportunity  to 
proceed  through  the  acquisition  life  cycle  quicker  than  developmental  programs. 
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The  MRDs  fostered  the  program’s  acquisition  cycle  to  reach  FRP 
in  five  years.  This  short  timeframe  fosters  cost  savings  for  the  program  compared  to 
other  large  ACAT  I  programs  from  the  1980’s.  A  report  from  the  President’s  Blue 
Ribbon  Commission  on  Defense  Management  provides  the  information  for  the  time 
period. 


But  a  much  more  serious  result  of  this  [acquisition]  management 
environment  is  an  unreasonably  long  acquisition  cycle  -  ten  to  fifteen 
years  for  our  major  weapon  systems.  This  is  a  central  problem  from 
which  most  other  acquisition  problems  stem: 

•  It  leads  to  unnecessarily  high  costs  of  development.  Time  is  money,  and 
experience  argues  that  a  ten-year  acquisition  cycle  is  clearly  more 
expensive  than  a  five-year  cycle. 

•  It  leads  to  obsolete  technology  in  our  field  equipment.  We  forfeit  our  five- 
year  technological  lead  by  the  time  it  takes  us  to  get  our  technology  from 
the  laboratory  into  the  field 

•  And  it  aggravates  the  very  gold-plating  that  is  one  of  its  causes.  Users, 
knowing  that  the  equipment  to  meet  their  requirements  is  fifteen  years 
away,  make  extremely  conservative  threat  estimates.  Because  long-term 
forecasts  are  uncertain  at  best,  users  tend  to  err  on  the  side  of  overstating 
the  threat.  (1986,  p.  47) 

The  commission  provides  analysis  on  the  impacts  of  long-term 
programs.  The  HMMWV’s  MRDs  provide  efficiency  to  the  program  by  keeping  the 
program  from  having  a  long  acquisition  cycle.  This  also  keeps  the  program  from  wasting 
money  on  requirements  for  expired  technologies. 

Factors  such  as  oversight,  contracting  lead  time,  requirements 
generation,  complexity  of  the  system,  and  testing  requirements  were  more  methodically 
thought  out  with  little  pressure  to  minimize  cycle  time.  Requirements  documents  took  a 
long  time  to  write,  staff,  finalize,  and  approve.  CJSCI  3170.01B  directs  that  the  time 
period  required  to  process  and  approve  MRDs  should  not  surpass  121  days  (CJCS,  2001, 
p.  B-10).  However,  in  the  newer  versions  of  CJSCI  3170.01C-H  there  is  no  reference  to 
outline  time  required  for  MCDs  to  be  processed  and  approved.  This  provided  a  standard 
time  for  program  offices  to  expect  to  receive  approved  MRDs  during  RGS.  The  program 
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office  would  know,  within  reason,  the  length  of  time  to  receive  approved  MRDs  and  have 
a  greater  opportunity  for  staying  on  their  program’s  projected  schedule. 

Then  in  1996,  the  DoD  put  guidance  out  to  the  acquisition 
community  to  reduce  program  costs  by  10%  while  maintaining  the  same  required  number 
of  platforms.  The  PM  HMMWV  conducted  an  additional  analysis  for  cost  savings.  This 
analysis  provided  two  examples  of  requirements  in  the  MRD  that  could  be  eliminated  to 
increase  efficiencies  for  cycle  time  and  cost.  One  example  is  a  requirement  for  tire  jacks. 
Each  HMMWV  was  issued  a  tire  jack  but  was  not  issued  a  spare  tire.  An  efficiency  that 
could  have  been  gained  from  the  removing  the  requirement  was  cost  savings.  Since  there 
is  no  requirement  for  a  spare  tire,  the  requirement  for  a  jack  should  be  removed. 
Recovery  support  would  be  needed  to  bring  a  new  tire,  and  the  same  support  could  also 
provide  the  jack,  thus  producing  cost  savings  in  PM  HMMWV  by  not  having  to  purchase 
jacks  for  each  vehicle.  Costs  are  being  created  for  a  requirement  that  does  not  directly 
associate  to  a  need  for  the  warfighter  operating  the  vehicle.  This  cost  translates  into  an 
unsound  investment  by  purchasing  unneeded  tire  jacks  for  each  HMMWV  which  detracts 
from  efficiency  for  the  program. 

The  HMMWV  also  had  the  requirement  to  be  painted  with  a 
special  coating  that  makes  it  resistant  to  chemical  agents  (B.  Naegle,  personal 
communication,  April  26,  2013).  Unlike  the  armored-track  vehicles,  the  paint  is 
ineffective  for  the  HMMWV.  It  serves  to  make  the  body  of  the  HMMWV  resistant  to 
chemicals,  but  the  rest  of  the  HMMWV  could  not  be  decontaminated  with  its  rubber 
wheels,  exposed  wires,  and  open  engine  system  (B.  Naegle,  personal  communication, 
April  26,  2013).  This  example  shows  an  increase  in  program  cost  and  time  required  to 
produce  a  vehicle.  Had  collaboration  occurred  to  produce  a  more  efficient  MRD  there 
would  have  been  benefits  to  costs  and  time.  The  example  demonstrates  that  the  inability 
to  remove  the  chemical  paint  requirement  continued  to  maintain  a  program  at  the  same 
level  of  costs,  when  there  could  have  been  savings  by  removing  the  paint.  Additionally, 
the  paint  process  increases  the  cycle  time  for  the  vehicle  to  be  ready  to  be  released  to  the 
warfighter.  Thus,  this  reduces  the  efficiency,  in  the  form  of  cost  savings  and  time,  by 
being  unable  to  eliminate  the  requirement  for  tire  jacks  and  the  special  paint  coating. 
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The  PM  HMMWV  recognized  the  constraints  of  the  requirements 
outlined  in  the  documents.  In  many  cases,  the  PM  worked  within  these  constraints  to 
make  sound  investments  and  avoid  costs.  However,  the  same  responsibility  exists  with 
all  other  stakeholders  in  the  requirements  process  to  examine  the  requirements  to 
determine  whether  cost  savings  are  achievable. 

/.  HMMWV  Better  Buying  Power  2.0  Effectiveness  Analysis 

(1)  Eliminate  Redundancy  Within  Warfighter  Portfolios 

Rating:  Poor. 

The  HMMWV  accomplished  the  initial  intent  of  the  requirements 
documents.  The  M151  Jeep,  M880  and  M561  Utility  Trucks,  and  the  M792  Ambulance 
were  all  decommissioned  from  the  active  Army  fleet  as  the  HMMWV  FoV  were  fielded 
to  units. 

HMMWV  was  a  joint  program  from  the  beginning  as  it  replaced  1  1/4  ton 
trucks,  3/4  ton  trucks,  and  the  “1/4  ton  light  truck,  General  Purpose,”  or 
GP  (Jeep)  which  were  ubiquitous  through  all  of  the  [Sjervices.  The  multi¬ 
purpose  moniker  is  real,  and  numerous  different  vehicles  were  replaced 
with  the  HMMWV.  (B.  Naegle,  personal  communication,  April  26,  2013) 

The  requirements  document  outlined  four  land  warfare  mission 
areas  of  close  combat,  fire  support,  ground  air  defense,  and  land  combat  support.  The 
HMMWV  program  provided  variants  for  each  of  these  needs  while  maintaining 
commonality  of  the  chassis  and  adhering  to  its  functional  objectives  of  mobility,  payload, 
survivability,  and  transportability. 

The  issue  with  the  HMMWV  was  the  additional  utilization  as  it 

became  the  largest  wheeled  vehicle  fleet  in  the  military  for  its  time.  The  more  the 

HMMWV  was  being  used  by  the  Army,  the  more  the  warfighters  needed  the  HMMWV 

to  do  in  order  to  meet  their  various  missions.  The  warfighters  began  to  push  the 

limitations  of  the  HMMWV  to  augment  other  areas  within  the  warfighter  portfolio.  The 

logistics  community  continued  to  load  the  HMMWV  beyond  its  initial  payload  for 

resupply  operations.  The  HMMWV  could  not  meet  this  need.  Requirements  expansion 

continued  to  the  point  where  a  2-1/2-ton  truck  was  considered  by  the  PM  Light  Tactical 
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Vehicles  to  meet  the  additional  needs  of  the  logistics  community  (B.  Naegle,  personal 
communication,  April  26,  2013).  The  HMMWV  was  no  longer  relevant  to  the  needs  of 
the  logistics  community.  However,  that  platform  consideration  was  cancelled.  Had  the 
program  not  been  canceled,  then  redundancy  would  have  been  created  from  the  existence 
of  two  programs  with  similar  requirements  for  managing  materiel  solutions.  Instead, 
greater  increases  in  the  HMMWV’s  requirements,  such  as  payload  capabilities,  occurred 
to  meet  the  emerging  capabilities  of  the  warfighter. 

The  PM  HMMWV  conducted  interchange  conferences  with  the 
other  PM  offices  that  wanted  to  integrate  their  product  on  the  HMMWV.  However,  once 
the  HMMWV  was  in  the  fleet,  the  PM  HMMWV  soon  lost  control  of  configuration 
management.  The  PM  HMMWV  began  to  receive  redundant  requirements,  such  as 
additional  lighting,  improved  global  positioning  system  (GPS),  jammers,  and  improved 
armor  capabilities.  Thus  the  program  had  to  continually  conduct  new  testing  that 
absorbed  a  great  deal  from  their  budget.  As  the  new  capabilities  were  integrated  into  the 
system  the  older  capabilities  were  still  being  used.  For  example,  company  commanders 
could  use  a  PLGR  (precision  lightweight  GPS  receiver)  in  one  vehicle  or  use  a  DAGR 
(defense  advanced  GPS  receivers)  in  a  different  vehicle  within  their  company’s  vehicle 
fleet  (Aboona,  2007).  TRADOC,  external  PM  offices,  and  PM  HMMWV  efforts  were 
not  coordinated  in  managing  or  developing  the  requirements.  The  other  PM  offices  no 
longer  needed  to  go  to  PM  HMMWV  to  acquire  a  vehicle  to  conduct  integration.  The 
other  PM  offices  could  easily  acquire  a  HMMWV  almost  anywhere  and  conduct  their 
own  integration,  Figure  22,  without  fully  understanding  many  important  aspects  of  the 
HMMWV,  such  as  its  power  capacity. 
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Ml  1 14  /  Golden  HMMWV  Power 
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Figure  22.  Ml  1 14  Golden  HMMWV  Power  (From  Aboona,  2007,  slide  1) 


The  issue  of  configuration  management  was  compounded  once 
soldiers  could  purchase  commercial  off-the-shelf  (COTS)  products  and  conduct  their  own 
integration  of  whatever  they  wanted,  such  as  loudspeakers  and  reinforced  bumpers. 

(2)  Improve  Requirements  Definition;  Prevent  Requirements 


Creep. 


Rating:  Poor 

The  MNS  and  ORDs’  requirements  for  the  HMMWV  were 
outlined  by  the  CBTDEV;  however,  the  HMMWV  became  the  victim  of  being  the 
platform  of  choice.  This  resulted  in  PM  HMMWV  continuously  inserting  capabilities  to 
fill  additional  capability  gaps.  The  HMMWV  fleet  eventually  reached  approximately 
100,000  trucks  used  in  full  spectrum  operations  across  the  Army  and  the  other  Services. 
“We  could  not  control  the  appetite  for  people  wanting  to  change  the  HMMWV,”  stated 
Brad  Naegle  (personal  communication,  April  26,  2013).  Moreover,  as  the  CBTDEV 
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identified  capability  gaps,  and  new  requirements  were  generated  for  PM  HMMWV  to 
integrate  into  the  material  soution,  (B.  Naegle,  personal  communication,  April  26,  2013). 

The  PM  HMMWV  was  constantly  catching  up  to  everything  that 
was  being  integrated  on  their  vehicles.  The  PM  could  not  fully  identify  what  was  in  the 
warfighter’s  portfolio  or  the  many  capabilities  being  used  on  the  platform.  Moreover,  as 
the  CBTDEV  identified  capabilities,  it  would  write  new  requirements  for  the  PM 
HMMWV  to  integrate.  One  such  requirement  was  to  increase  the  payload  capability  of 
the  platform  (B.  Naegle,  personal  communication,  April  26,  2013). 

Much  like  the  BBP  2.0  initiative  of  building  stronger  partnerships 
with  the  requirements  community  to  control  costs,  the  CBTDEV  needed  to  assist  the 
program  office  in  defining  the  requirements  and  minimizing  requirements  creep. 
TRADOC  had  established  guidance  that  units  could  not  modify  the  HMMWV.  Instead, 
they  leveraged  these  HMMWV  modifications  to  produce  new  requirements.  That  is  not 
to  say  that  the  warfighter  does  not  produce  great  ideas  for  modification.  Soldier 
innovations  have  proven  this  time  and  time  again.  Nevertheless,  requirements  creep  must 
be  identified  and  not  perpetuated. 

Cross-functional  teams  did  not  exist  to  formulate  and  manage 
requirements.  The  PM  HMMWV  was  overwhelmed  by  the  constant  flow  of  additional 
requirements.  This  issue  was  only  exacerbated  as  the  HMMWV  was  being  used  more 
and  more  in  the  GWOT.  Another  ONS  was  submitted  in  2003,  for  a  modified  HMMWV 
with  additional  protection.  The  2004  ORD  in  response  to  the  ONS  was  as  follows: 

Overall  Mission  Area.  The  HMMWV  mission  is  to  provide  a  light  tactical 
wheeled  vehicle  for  command  and  control,  troop  transport,  light  cargo 
transport,  shelter  carrier,  ambulance,  towed  weapons  prime  mover,  and 
weapons  platform  throughout  all  areas  of  the  battlefield  or  mission  area 
(e.g.,  peacekeeping).  For  units  that  require  specific  vehicle  configurations, 
the  detailed  requirements  will  be  provided  in  kit  form,  capable  of  being 
installed  at  GS  maintenance  level  or  below,  or  by  incorporation  of 
Component  of  Major  End  Items  (CMEI)/Component  of  End  Items  (COEI) 
by  the  system  integrator.  (JROC,  2004,  p.  1) 
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The  2004  ORD  based  on  the  receipt  of  the  ONS  drove  the 
production  of  upgrades  to  produce  a  desired  survivability  capability.  However,  this 
capability  continued  to  grow  and  evolve  with  the  enemy  threat,  as  expected. 

We  ramped  up  the  production  line  there  from  a  Ysic\  up  armor  Humvee. 

We  had  to  design,  develop,  test,  modify  and  field  an  add-on  armor  kit,  and 
then  just  a  series  of  upgrades.  It’s  been  a  case  of  where  you  get  a  basic 
capability  to  the  field  as  quickly  as  possible,  have  some  type  of  feedback 
mechanism  forward  in  the  field,  you  know,  once  the  soldiers  tell  you  what 
works  and  what  doesn’t  and  the  threat  continues  to  evolve  and  you’ve  got 
to  have  a  system  to  set  up  here  and  upgrade.  (K.  Peterson,  personal 
communication,  October  24,  2012). 

The  MRDs,  on  the  other  hand,  did  not  capture  the  growing 
requirement  all  at  once. 

Within  the  ORD,  there  were  no  requirements  for  electronic  warfare 
systems,  Objective  Gunner’s  Protective  Kit  (OGPK),  additional  radio  mount,  navigation 
system,  driver’s  vision  enhancement  systems,  automatic  fire  extinguishing  systems,  air 
conditioning,  or  other  additional  requirements.  “Some  things  [requirements]  have  the 
right  traceability,  but  you’ll  see  other  things  like  a  gunner  protection  kit  on  top  of  a 
HMMWV  and  there’s  no  requirement  for  that  where  it  started”  (K.  Peterson,  personal 
communication,  October  24,  2012).  These  additional  requirements  were  the  products  of 
warfare,  emerging  warfighter  needs,  other  PM  initiatives,  and  ever-changing  threats  on 
the  battlefield.  These  requirements  were  not  anticipated  in  the  writing  of  the  2004  ORD 
because  the  CBTDEV  was  not  aware  of  the  requirements  for  these  special  items. 

In  spite  of  this,  in  the  race  to  contribute  to  GWOT,  requirements 
creep  grew  at  an  uncontrollable  rate  for  the  HMMWV.  Every  additional  requirement 
added  to  the  HMMWV’ s  size,  weight,  and  power  requirements.  Eventually,  the 
HMMWV  would  fail  in  many  of  its  requirements.  It  was  no  long  air  transportable  by  any 
aircraft  or  air  droppable  by  any  rotary- wing  asset  during  sling-load  operations.  It  met  the 
requirements  of  the  initial  documents  but  simply  could  not  keep  up  with  requirements 
creep  from  new  and  emerging  technologies. 
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The  HMMWV  would  be  replaced  in  Iraq  and  Afghanistan  by  the 
MRAP  because  the  HMMWV  platform  could  not  meet  the  challenges  of  creeping 
requirements.  The  warfighters  needed  a  more  survivable  and  maneuverable  platform  that 
could  handle  the  size,  weight,  and  power  requirements  of  both  theaters  of  war.  This 
revolutionary  change  was  necessary  because  the  HMMWV  was  no  longer  efficient  in 
meeting  the  challenges  of  the  GWOT.  The  HMMWV  met  its  initial  mission  to  replace 
older  vehicles  in  the  DoD’s  fleet,  although  it  was  never  designed  for  the  requirements 
that  continued  to  grow  during  the  GWOT.  It  is  essential  that  performance  requirements 
are  scrutinized  and  that  cross -functional  teams  are  created  in  order  to  better  manage 
emerging  capability  gaps  and  prepare  more  requirements  documents.  Figure  23  is  the 
HMMWV’s  MRDs  scorecard. 

g.  HMMWV  Efficiency  and  Effectiveness  Analysis 


BBP  2.0  Principles  and  Initiatives 
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Figure  23.  HMMWV  Overall  Rating  Scorecard 
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Overall  Score 


Efficiency:  1  x  Poor,  1  x  Average 
Effectiveness:  2  x  Poor 

Figure  24  depicts  our  overall  rating  of  the  HMMWV’s  MRDs. 


Figure  24.  HMMWV  Efficiency  and  Effectiveness  Analysis 
(After  Griiter  &  Boerendans,  2013) 


Overall  Rating 
Efficiency:  Poor-Average 
Effectiveness:  Poor 

The  HMMWV  MRDs  receives  an  efficiency  rating  of  poor-average.  Our 
analysis  reveals  that  efficiency  was  gained  by  the  HMMWV’s  acquisition  cycle.  The 
program’s  acquisition  cycle  was  less  than  half  the  time  of  other  ACAT  I  programs  during 
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the  1980’s.  Additionally,  efforts  between  key  stakeholders  were  poorly  synchronized  and 
the  PM  office  had  difficulty  establishing  collaboration.  Their  initial  relationship  with 
their  requirements’  partners  could  have  been  improved  to  be  more  synchronized.  Better 
collaboration  between  stakeholders  would  have  increased  the  efficiency  of  the 
partnership  between  the  user  community  and  the  program  office  required  to  meet  the 
needs  of  the  warfighter.  Lines  of  communication  between  the  stakeholders  started  out 
with  little  collaboration  and  eventually  transitioned  to  receiving  direct  feedback  from  the 
warfighter.  Thus,  MRDs  yielded  low  efficiency  for  PM  HMMWV  to  execute  their 
mission  and  make  sound  investments  with  their  funding. 

The  HMMWV  receives  a  rating  of  poor  for  effectiveness.  The  HMMWV 
provided  a  truck  that  effectively  replaced  the  M151  Jeep,  M880  and  M561  Utility  Trucks, 
and  the  M792  Ambulance  with  commonality  based  off  its  requirements  documents. 
However,  requirements  creep  and  redundancy  became  an  issue  for  the  platform  as 
changes  and  modifications  were  being  made  to  the  platform.  The  HMMWV  MRDs 
began  creating  redundancy  for  the  program  through  the  analysis  of  adding  the  2  Vi  ton 
truck  program.  Requirements  creep  also  emerged  in  the  form  of  increased  capabilities  in 
response  to  the  2  Vi  ton  truck  program  and  the  vehicles  role  and  utilization  within 
GWOT.  Each  of  these  instances  produced  the  MRDs  effectiveness  rating  observed  in 
Figure  24. 

The  HMMWV  has  been  in  the  Army’s  fleet  for  nearly  three  decades  and 
has  undergone  the  experience  of  both  the  RGS  and  the  JCIDS.  While  the  PM  HMMWV 
has  never  had  to  execute  the  documents  of  the  JCIDS,  it  has  experienced  the  dynamics  of 
a  new  requirements  generation  process.  Also,  many  of  the  additional  retrofits  integrated 
on  the  platform  have  had  to  undergo  these  new  requirements  documents.  The  transition 
between  RGS  and  JCIDS  has  often  made  it  difficult  for  the  HMMWV  to  adapt  to  the 
many  emerging  requirements.  The  RGS  had  been  a  well-established  process  adopted  by 
the  workforce.  The  HMMWV  was  in  the  transition  between  one  RGP  to  the  next. 


97 


2.  Mine  Resistant  Ambush  Protected  All-Terrain  Vehicle  (M-ATV) 

Of  note,  some  information  was  drawn  directly  from  the  researcher’s  (Anh  Ha) 
personal  experience  serving  as  the  APM  M-ATV  prior  to  this  project.  Information 
referenced  from  the  researcher  was  done  in  an  objective  manner  only  to  provide 
information  about  specific  sub-systems  integrated  onto  the  M-ATV  platform.  An  image 
of  the  M-ATV  is  shown  in  Figure  24  below. 


Figure  25.  M-ATV  (A.  H.  Ha,  personal  communication,  April  13,  2013) 


a.  Mission 

“The  MRAP  All-Terrain  Vehicle  (M-ATV)  is  used  in  small  unit  combat 
operations  in  highly  restricted  rural,  mountainous,  and  urban  environments.  Missions 
include  mounted  patrols,  reconnaissance,  security,  convoy  protection,  communications, 
command  and  control,  and  combat  service  support”  (PM  M-ATV,  2013). 
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b. 


Vision 


“We  are  a  cohesive,  people-oriented,  rapid-response,  jointly  coordinated 
program,  focused  on  new  technologies,  organized  and  coordinated  to  efficiently  provide 
effective  capabilities  to  Warfighters  and  customers”  (PM  M-ATV,  2013). 

c.  Focus 

The  Product  Manager  MRAP  All-Terrain  Vehicle  (PdM  M-ATV) 
manages  the  M-ATV,  designed  to  provide  MRAP  levels  of  protection  with 
greater  off-road  mobility  in  the  Afghanistan  theater  of  operations.  The  first 
M-ATVs  were  issued  to  combat  units  in  Afghanistan  in  December  2009, 
just  160  days  after  contract  award.  The  fielding  of  these  lifesaving 
vehicles  marked  a  significant  milestone  achieved  by  the  MRAP  Joint 
Program  Office  (JPO)  to  protect  the  Warfighters  with  a  highly  survivable 
and  off-road-capable  vehicle.  In  addition  to  its  ability  to  traverse  a  wide 
variety  of  terrain,  its  speed  transforms  it  from  simply  a  means  of 
transportation  to  an  offensive  capability.  The  lighter  weight  and  smaller 
size  also  lend  the  vehicle  to  somewhat  easier  transportability.  The  M-ATV 
can  carry  up  to  five  personnel — four  plus  a  gunner.  (PM  M-ATV,  2013) 

d.  M-ATV  Background 

The  M-ATV  was  acquired  and  fielded  as  a  result  of  rapid  acquisition 
initiatives  in  support  of  the  GWOT.  In  September  2008,  the  capability  need  for  the  M-ATV 
came  from  Operation  Enduring  Freedom  in  Afghanistan.  The  M-ATV  was  developed  from 
the  minimum  amount  of  requirements  documents  due  to  the  urgent  and  compelling  needs  of 
the  warfighter.  The  M-ATV  program  was  an  amendment  to  the  original  JUONS  CC-0326 
from  November  2006  and  did  not  require  a  CDD  since  it  was  a  COTS  materiel  solution  and 
used  an  amended  CPD  V 1  approved  in  May  2007  for  production. 

By  December  2008,  a  request  for  proposal  was  released,  and  source 
selection  was  completed  by  the  end  of  June  2009.  Oshkosh  Defense  was  awarded  the 
initial  contract  for  over  5,000  vehicles.  CPD  1.1  for  the  M-ATV  was  approved  in  the 
beginning  of  July  2009  and  the  start  of  work  began  by  the  end  of  July.  The  M-ATV 
received  its  first  major  ECP  in  order  to  support  the  Command,  Control,  Communications, 
Computers,  Intelligence,  Surveillance  and  Reconnaissance  (C4ISR)  upgrade,  after  the  first 
200  M-ATVs  had  already  been  accepted  by  the  government  in  mid- August.  The  approved 
solution  was  tested  and  cut  into  integration  at  SPAWAR  (Space  and  Naval  Warfare 
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Systems  Command)  South  Carolina  by  the  end  of  September  2009.  In  the  beginning  of 
October  2009,  the  first  M-ATV  arrived  in  Afghanistan  and  was  fielded  to  the  warfighter. 
Figure  26  outlines  the  life  cycle  of  the  M-ATV  and  the  MRAP  Programs’  requirements 
documents.  The  squares  outlined  in  red  show  the  events  specific  to  the  M-ATV. 


Figure  26.  MRAP  Requirements  Timeline  (After  Johnson  &  Iovannitti,  2010,  p.  8) 


The  JPO  MRAP  used  many  tools  to  ensure  the  vehicle  met  the  desired 
capabilities  and  requirements  of  the  warfighters  during  its  development.  One  of  the  main 
tools  used  by  the  program  office  was  a  requirements  traceability  matrix  (RTM).  The 
RTM  provides  a  way  to  ensure  traceability  of  all  requirements  for  the  specific  product  or 
system  (Ofni  Systems,  n.d.).  This  traceability  allows  the  ability  to  trace  each  requirement 
to  a  measureable  factor  that  can  be  tested  (Ofni  Systems,  n.d.).  This  allows  for  validation 
and  verification  of  each  requirement  and  capability. 

While  the  M-ATV  has  never  undergone  full-rate  production,  the  program 
has  produced  over  8,000  M-ATVs  in  five  separate  LRIPs.  The  M-ATVs  were  produced 
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in  LRIPs  15,  16,  17,  21,  and  22.  The  JUONS  and  CPD  were  the  requirements  documents 
we  evaluated  in  our  analysis. 

The  M-ATV  is  a  materiel  solution  that  existed  after  the  inception  of  the 
JCIDS.  The  M-ATV’s  life  cycle  continues  through  the  modifications  of  the  JCIDS. 
While  the  JCIDS  was  enacted  in  June  2003,  as  per  CJCSI  3170.01F  (CJCS,  2007), 

c.  JCIDS  recognizes  that  there  are  many  sources  for  capability  needs 
including:  Joint  Urgent  Operational  Needs  (JUONs)... for  immediate 
needs,  combatant  commander’s  integrated  priority  lists  (IPL),  lessons 
learned,  transitioning  improvised  explosive  device  (IED)  initiatives  ..., 
etc.  Once  these  sources  have  been  reviewed  and  approved  by  the  JROC, 
they  will  enter  the  JCIDS  and  acquisition  processes  at  Milestone  B  or  C. 
(p.A-1) 

Additionally, 

(10)  Other  sources  may  be  used  to  justify  entering  the  JCIDS  process 
without  a  JCD  or  ICD.  These  sources  include  combatant  commander  IPL, 
joint  and  Service  lessons  learned,  joint  assessments  (e.g.,  War  on 
Terrorism),  JUONs,  Service  urgent  needs,  IED  defeat  initiatives, 
JCTDs/ACTDs,  qualified  prototype  projects,  and  quick  reaction 
technology  projects.  Once  the  JROC  has  validated  the  gap  identified  in  the 
source,  the  sponsor  can  initiate  development  of  a  CDD  or  CPD  as 
appropriate.  (CJCS,  2007,  pp.  A-7-8) 

Requirements/Capabilities  Documents 

ICD:  None.  The  M-ATV  initial  capabilities  document  was  an  amendment 
to  JUONS  CC-0326.  The  M-ATV  went  from  JUONS  to  CPD. 

General  Description 

JUONS  CC-0326  was  the  document  that  facilitated  the  MRAP  family  of 
vehicles  (FoV).  The  JUONS  identified  the  urgent  need  for  a  protected  vehicle  capability 
that  increased  survivability  and  mobility  of  forces  operating  in  a  hazardous  fire  area  or 
combat  zones  against  threats  that  included  mines,  IEDs,  Explosively  Formed  Penetrators 
(EFP),  RPGs,  RKG-3  grenades  and  small  arms  fire  (SAF)  in  the  Area  of  Operations  (AO). 
The  Army  Tactical  Wheeled  Vehicle  Strategy  shows  the  development  of  the  current  M- 
ATV  from  its  operational  requirements  that  were  contained  in  the  original  JUONS. 
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M-ATV — Used  for  combat  operations  in  complex  and  highly  restricted 
rural,  mountainous,  and  urban  terrain.  The  M-ATV  provides  better  overall 
mobility  characteristics  than  the  original  CAT  I,  II,  and  III  MRAP  vehicle 
variants  and  provides  better  survivability  characteristics  than  any  variant  of 
HMMWV.  The  M-ATV  supports  mounted  patrols,  reconnaissance, 
security,  convoy  protection,  casualty  evacuation,  DI  and  C2  functions; 
carries  up  to  five  personnel.  (Office  of  the  Vice  Chief  of  Staff,  2010,  p.  12) 

Because  the  enemy  exploits  known  ground  lines  of  communications 
(GLOCs)  with  ambushes  and  IED  and  small  arms  fire,  Joint  Forces  need  vehicles  that 
enable  them  to  survive  the  first  attack  and  counter  attack  (JPO  MRAP,  2010). 

The  amendment  to  JUONS  CC-0326  requested  a  smaller  variant  of  the 
MRAP  in  support  of  OEF.  The  warfighter  needed  a  lighter  vehicle  platform  with  the 
capability  to  traverse  the  rigorous  terrain  of  Afghanistan.  The  PM  M-ATV  continues  to 
use  the  JCIDS  documents  to  support  their  program. 

e.  M-ATV  Better  Buying  Power  2.0  Efficiency  Analysis 

(1)  Build  Stronger  Partnerships  With  the  Requirements 
Community  to  Control  Costs. 

Rating:  Average 

Initially,  the  requirements  community  and  the  PM  office  were  well 
synchronized  in  producing  the  MCD  for  the  base  model  of  the  M-ATV  (D.  Krawchuk, 
personal  communication,  April  13,  2013).  Everyone  at  every  echelon  understood  the 
urgency  of  the  capabilities  needed  by  the  warfighters  in  Afghanistan  and  that  a  quality 
CPD  was  needed  to  maximize  the  efficiency  of  the  M-ATV’ s  production.  The 
requirements  of  the  base  model  were  dutifully  coordinated  and  portrayed  by  the 
CBTDEV  to  the  JPO  MRAP.  Most  discrepancies  were  quickly  defined  by  the  CBTDEV 
in  order  to  ensure  the  right  solution  would  be  fielded  in  OEF. 

I  would  say  the  only  ones  that  we  saw  staffed  and  we  had  an  opportunity 
to  chop  off  on  was  the  MATV  CPD.  I  mean  we  did  go  back  and  forth 
with  them  so  that — because  they  were  writing  it  very  performance 
oriented.  So  that  was  a  good  thing.  Some  of  the  performance  that  they  had 
in  and  their  thresholds  were  kind  of  beyond  what  we  believe  the  state  of 
the  art  to  be,  so  we  negotiate  with  them  so  that  it  wasn’t.  That  was  kind  of 
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the  whole  staffing  part  of  it.  We  will  try  to  get  you  as  much  as  we  can 
within  the  confines  of  what  is  written,  but  we  don’t  want  to  agree  at  a 
threshold  level  to  give  you  something  that  we  do  not  know  can  be  met.  (D. 
Krawchuk,  personal  communication,  February  13,  2013) 

Additionally,  the  CBTDEV  assisted  in  the  source  selection  process 
to  represent  the  requirements  community.  This  is  a  one  of  the  biggest  reasons  that  M- 
ATVs  were  able  to  be  fielded  in  16  months  (D.  Krawchuk,  personal  communication, 
February  13,  2013). 

However,  the  CBTDEV  continuously  received  capability  gaps 
from  theater  and  contacted  the  program  office  for  a  potential  solution  to  meet  each 
capability  gap.  The  JPO  MRAP  and  the  CBTDEV  did  have  an  open  line  of 
communication  between  their  organizations;  although  the  lack  of  fully  understanding  the 
dynamics  of  each  other’s  organizational  processes  inhibited  them  from  fully  efficiently 
developing  requirements  for  both  stakeholders.  The  program  office  did  not  fully 
understand  the  operations  of  TRADOC,  nor  did  the  CBTDEV  understand  the  acquisition 
process  that  a  program  office  must  follow.  Although  TR  71-20  outlines  the  process  for 
requirements  determination,  the  actual  process  was  not  strictly  adhered  to  due  to  the  lack 
of  knowledge  and  understanding.  However,  MRAP  CBTDEVs  did  their  due  diligence 
and  wanted  to  meet  the  warfighter’s  needs  as  quickly  as  possible. 

As  mentioned  previously,  the  CPD  v2  was  amended  for  the  M- 
ATV  and  was  based  on  the  experiences  with  the  original  MRAP  CPD  vl.  PM  M-ATV 
and  the  MRAP  office  were  persistently  doing  more  with  less.  It  was  difficult  for  them  to 
train  sufficient  personnel  for  translating  user  requirements  into  system  specifications 
since  their  workforce  was  so  overstretched  with  ongoing  operations  to  meet  the 
warfighter’s  continuously  growing  needs.  The  JPO  MRAP  relied  heavily  on  those  with 
past  experience.  Many  of  these  personnel  were  also  in  key  leadership  positions,  and 
writing  the  system  specifications  was  an  additional  duty  to  their  daily  roles.  The  lack  of  a 
knowledgeable  acquisition  workforce  from  the  younger  generation  limited  their 
collaboration  with  the  CBTDEV.  The  collaboration  between  the  program  office  and  the 
CBTDEV  was  crucial  for  all  stakeholders  to  clearly  meet  the  needs  of  the  warfighter 
from  inception  to  materiel  solution. 


103 


The  memorandum  on  the  MRAP  FoV,  shown  in  Figure  27,  shows 
the  DoD’s  acceptance  of  the  requirements  documentation  of  the  MRAP  thus  far. 


JROCM  080-12 
30  May  2012 


MEMORANDUM  FOR:  Distribution  List 

Subject:  Mine  Resistant  Ambush  Protected  Family  of  Vehicles 

1-  The  Joint  Requirements  Oversight  Council  (JROC)  acknowledges  that  fielded  Mine 
Resistant  Ambush  Protected  (MRAP)  vehicles  do  not  meet  all  the  performance 
requirements  of  the  Capabilities  Production  Documents  (CPDs)  found  in  version  1.0 
(JROCM  109-07,  MRAP,  dated  10  May  2007)  and  1.1  (JROCM  1 15-09,  MRAP  CPD 
Version  1.1,  dated  7  July  2009). 

2.  Based  upon  empirical  evidence  of  the  MRAP  Family  of  Vehicles'  (FoV)  performance  in 
theater,  the  currently  fielded  vehicles  have  demonstrated  acceptable  operational 
capabilities  and  force  protection  in  support  of  combat  operations. 

3.  The  JROC  directs  the  following: 

a.  The  23  enduring  variants  of  the  current  MRAP  fleet  listed  in  Enclosure  A  are 
waived  from  meeting  CPD  1.0  and  CPD  1.1. 

b.  The  enclosed  MRAP  Performance  Baseline  (MPB)  is  the  acceptable  minimum 
requirements  standard  for  the  MRAP  FoV.  The  MPB  becomes  the  basis  for  supporting 
service  materiel  release  for  the  variants  identified  therein. 


c.  For  modernization  of  the  current  fleet,  the  Services  are  encouraged  to  achieve 
CPD  1.1  capabilities  where  possible  as  resources  and  priorities  permit. 

d.  CPD  1 . 1  is  the  approved  requirements  document  for  future  competitive  MRAP 
vehicle  procurements. 


4.  The  JROC  further  directs  the  Marine  Corps,  as  MRAP  lead  Service  and  in  coordination 
with  the  other  Services,  to  review  CPD  1.1  and  report  back  to  the  Protection  Functional 
Capabilities  Board  within  six  months  whether  CPD  1 . 1  should  be  updated  to  ensure 
proper  synchronization  with  the  current  National  Security  Strategy  and  fiscal 
environment. 


JP 


I  _ ji 

AMESlA.  W1NNEFIJLD,  JF  . 
cfmiraA  United  States^Nav  y 
■^VfCe  Chairmanf 
of  the  Joint  Chiefs  ofStaff 


Enclosure: 


Figure  27.  Memo  on  the  JPO  MRAP  From  the  Vice  Chairman  of  the  Joints  Chiefs  of  Staff 

(From  JROC,  2012c,  p.  1) 


As  the  JPO  MRAP  grew  as  an  organization,  the  workforce’s 
expertise  also  grew  from  both  adaptable  senior  leadership  as  well  as  a  new  and  talented 
workforce  across  several  generations. 

Other  non-programs  of  record  may  want  to  emulate  what  JPO 
MRAP  has  done  to  validate  their  requirements  by  reaching  approval  through  a  program- 
created  tool,  a  “Performance  Baseline  Matrix.”  This  was  a  tool  used  by  the  program  to 
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explain  what  requirements  each  vehicle  within  the  MRAP  FoV  met.  Overall,  the 
shortfalls  and  best  practices  of  the  JPO  MRAP  must  be  recognized  for  future  evolution  of 
requirements  generation  and  validation  processes.  The  M-ATV  program  has  been 
identified  as  being  very  costly  but  necessary  for  preserving  life. 

The  MRAP  team  was  already  overtasked.  The  MRAP  FoV  had  the 
largest  footprint  in  both  Afghanistan  and  Iraq.  The  program  office  was  working  all  five 
phases  of  the  DAS  simultaneously.  They  were  constantly  receiving  new  requirements 
from  both  theaters  of  Iraq  and  Afghanistan,  they  were  conducting  technology 
development  for  additional  capabilities  required  for  the  MRAP  FoV,  they  were  executing 
additional  testing  on  new  capability  insertions,  they  were  still  in  production  of  many  of 
their  different  variants,  and  they  were  fielding  and  sustaining  the  MRAPs  in  both  theaters 
as  well  as  home  station  training  (M.  Minto,  personal  communication,  February  13,  2013). 
Since  2004,  the  JPO  MRAP  has  had  to  respond  and  answer  nearly  50  JUONS  to  enhance 
the  MRAP  FoV  and  balance  their  efforts  with  multiple  OEMs  (D.  Krawchuk,  personal 
communication,  February  13,  2013).  Figure  28  shows  the  MRAP  FoV. 


CAT  I  (379),  CAT  II  (1,905),  CAT  II  AUV  (70),  ARV  (2) 


CAT  I  (1,999),  CAT  II  (1,061),  CAT  III  (79) 


CAT  I  (7,474),  CAT  II  (16) 


M-ATV  (8,088) 831, 


Figure  28.  MRAP  Family  of  Vehicles  (From  Johnson  &  Iovannitti,  2010,  p.  9) 
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From  CPD  VI  to  CPD  V2,  the  JPO  MRAP  incorporated  over  30 
additional  JROC  approved  requirements  (D.  Krawchuk,  personal  communication, 
February  13,  2013).  These  additional  requirements  were  above  and  beyond  the  initial 
JUONS  and  CPD.  The  JPO  MRAP  conducted  its  own  case  study  in  order  to  assist  the 
DoD  and  CBTDEV  in  divesting  its  FoV  to  meet  the  needs  of  Army  MTO&E  (Office  of 
the  Vice  Chief  of  Staff,  2010).  Traditional  programs  of  record  must  follow  the  process  of 
the  life  cycle  management  system.  If  the  JPO  MRAP  were  to  become  a  program  of 
record,  they  realized  that  all  required  documentation  would  have  to  be  completed.  This 
meant  that  the  MRAP  program  would  have  to  start  from  the  beginning  of  the  life  cycle 
management  system  to  validate  their  program. 

The  JPO  MRAP  and  M-ATV  executed  requirements  validation. 
The  JPO  MRAP  and  the  CBTDEV  accomplished  this  by  cataloging  and  identifying  the 
requirements  outlined  in  multiple  documents  to  meet  definitive  requirements  as  a  result  of 
requirements  creep  (D.  Krawchuk,  personal  communication,  February  13,  2013).  The  JPO 
MRAP  would  strategically  analyze  their  governmental  emails,  orders,  requirements, 
presentations,  papers,  and  studies  to  understand  what  was  expected  from  the  program  by 
the  JROC  and  CBTDEV.  The  purpose  of  their  study  was  to  leverage  current  acquisition 
best  practices  to  understand  their  own  developmental  challenges  and  constraints.  The  JPO 
MRAP  objectively  examined  its  program  and  created  its  own  path  on  how  to  defeat  the 
bureaucracy  and  rigors  of  the  RGP  (M.  Minto,  personal  communication,  February  13, 
2013).  There  was  no  need  to  reaffirm  the  DAS  since  the  platform  was  already  showing 
success  in  a  combat  environment  (M.  Minto,  personal  communication,  February  13,  2013). 

Steps  taken  by  the  program  office  and  the  CBTDEV  to  begin 
remedying  the  situation  included  providing  a  validation  matrix  for  existing  MRAP 
platforms  to  receive  the  Vice  Chairman  of  the  Joint  Chiefs  of  Staffs  approval  for  future 
procurements  (D.  Krawchuk,  personal  communication,  April  13,  2013).  In  our  analysis, 
this  may  have  increased  the  efficiency  to  solve  an  issue  to  JROC  approved  requirements. 
However,  this  alternative  technique  did  not  adhere  to  the  outlined  process  of  JCIDS  or 
allow  the  MCDs  to  prevail.  This  produces  inefficiencies  through  means  of  circumventing 
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steps  that  have  been  developed  to  ensure  proper  collaboration  and  vetting  with  all 
necessary  stakeholders. 

The  JPO  MRAP  produced  capabilities  documents  that  validated 
vehicles  already  produced  and  utilized  by  the  warfighter.  The  JPO  MRAP  outlined  what 
they  understood  to  be  47  performance  criteria  required  to  meet  the  capability  gap  (D. 
Krawchuk,  personal  communication,  February  13,  2013).  The  program  office  identified 
what  capability  gap  that  each  platform  specifically  met.  In  summation,  JPO  MRAP  did 
not  have  to  spend  time  and  effort  in  order  to  reach  the  end- state  of  all  of  its  efforts  over 
the  past  decade.  It  received  approval  that  it  had  met  the  JCIDS  requirements  (JROC, 
2012c).  This  was  a  revolutionary  change  where  the  JPO  MRAP  was  the  first  of  many 
programs  that  were  initiated  by  the  JCIDS  rapid  acquisition  process. 

The  PM  M-ATV  and  the  requirements  community  did  not  agree  on 
many  requirements.  First,  the  CBTDEV  continued  to  push  for  a  TOW/ITAS  variant  of 
the  M-ATV.  The  CBTDEV  believed  it  was  as  simple  as  integrating  the  TOW/ITAS 
OGPK  turret  with  mount  onto  an  M-ATV.  The  requirements  for  TOW/ITAS  outlined  by 
the  CBTDEV  were  to  provide  an  M-ATV  where  the  missiles  were  stored  in  an  enclosed 
ballistic  case  and  the  missile  loader  did  not  have  to  dismount  the  truck  to  load  the  missile 
or  clear  the  back-blast  area,  while  at  the  same  time  not  taking  away  from  the  base 
model’s  survivability  and  maneuverability. 

In  reality  there  were  safety  issues,  the  need  to  maintain  the 

integrity  of  the  hull,  and  space  availability  constraints  that  would  not  allow  these 

requirements  to  be  met.  When  filled  with  the  basic  standard  load  of  water,  food,  ammo, 

medical  supplies,  and  nuclear,  biological  and  chemical  equipment,  the  only  place  to 

safely  store  missiles,  especially  when  considering  the  threat  of  IEDs,  was  in  the  bed  of 

the  M-ATV  (A.  Ha,  personal  communication,  April  13,  2013).  To  meet  the  ballistic 

requirement  to  enclose  the  missiles  would  require  an  enclosure  of  the  bed  area.  This 

would  take  away  from  the  truck’s  maneuverability  and  add  additional  constraints  to  the 

already  heavily  tasked  size,  weight  and  power  (SWAP;  A.  Ha,  personal  communication, 

April  13,  2013).  A  back  hatch  at  the  rear  of  the  hull  would  have  to  be  integrated  in  order 

to  meet  the  requirements  of  the  loader  to  egress  the  vehicle  without  dismounting  the 
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truck.  This  would  take  away  from  the  integrity  of  the  M-ATV’s  capsule-like  hull  and 
degrade  its  survivability. 

Additional  research  revealed  that  these  vehicles  would  not  be 
widely  used  in  Afghanistan  for  either  the  TOW/ITAS  or  the  ambulance  variant  of  the  M- 
ATV.  The  only  units  with  MTO&Es  that  required  TOW/ITAS  were  Infantry  Brigade 
Combat  Teams  (IBCT),  and  even  then  there  were  only  a  few  companies  that  had  the 
TOW/ITAS.  If  there  were  two  IBCTs  simultaneously  deployed  in  Afghanistan,  and  they 
were  to  mount  all  MTO&E  TOW/ITAS  systems  on  their  trucks,  there  would  be  a 
requirement  for  approximately  50  M-ATVs  to  have  this  capability.  The  IBCTs  seldom 
mounted  their  TOW/ITAS  on  patrols,  even  when  they  had  the  capability  on  the 
HMMWV. 

There  was  a  great  deal  of  conceptual  separation  between  the 
warfighter,  the  CBTDEV,  and  the  program  office.  This  separation  could  have  been 
prevented  by  performing  an  overarching  DOTMLPF  analysis  when  writing  the 
requirement.  A  great  deal  of  efficiency  was  lost  by  the  failure  to  have  a  better 
partnership  in  terms  of  time,  funding,  and  efforts.  Neither  the  TOW/ITAS  nor  the 
ambulance  platforms  were  effective. 

(2)  Reduce  Cycle  Times  While  Ensuring  Sound  Investment 

Decisions. 

Rating:  Average 

The  objectives  of  the  initiative  were  met  for  all  stakeholders  in 
many  aspects.  The  JPO  office,  TACOM’s  contracting  office,  the  testing  community,  and 
the  original  equipment  manufacturer  (OEM)  were  well  synchronized  in  order  to  quickly 
meet  the  needs  of  the  warfighter.  The  acquisition  strategy  of  the  PM  M-ATV  ensured 
that  few  discrepancies  existed  in  the  capabilities  documents  based  on  the  PM’s 
understanding  on  what  was  required  and  of  the  CBTDEV’s  writing  of  the  CPD.  The  PM 
M-ATV  used  many  of  the  same  personnel  to  assist  the  CBTDEV  who  had  written  the 
original  CPD  VI  on  the  amended  CPD  V2. 
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November  1,  2006  was  our  original  JUONS.  We  were  already  under 
contract  award  by  the  end  of  January.  Again,  the  beginning  of  May  was 
when  we  had  our  CPD  1.0.  We  have  a  CPD  1.0,  the  first  one,  which  was  1 
May  2007  and  our  CPD  1.1,  the  second  version,  was  July  7,  2009.  (D. 
Krawchuk,  personal  communication,  February  13,  2013) 

They  leveraged  the  experience  of  those  key  stakeholders  from 
original  the  MRAP  CPD  and  had  undergone  the  JROC  approval  process. 

Many  of  these  personnel  also  had  already  built  the  essential 
relationships  with  stakeholders  in  the  Pentagon. 

As  for  CPDs  running  through  the  JCIDS  process,  I  don’t  know  what  you 
have  seen,  but  prior  to  MRAPs  and  some  other  programs  I  was  on,  we 
were  looking  at  a  year  or  a  year  plus  to  get  a  CPD  written,  staffed  and 
approved.  Since  we  had  contractors  who  happened  to  understand  the 
JCIDS  process.  We  went  from  a  contract  with  WBB  [Whitney,  Bradley 
and  Brown,  Inc.]  to  say,  “Help  us  get  a  CPD  written  and  approved,”  to  an 
approved  CPD  within  two  months.  It  was  on  an  ultra-short  fuse  that  we 
got  this  stuff  approved  in  no  time  at  all.  The  good  thing  is  yes,  you  got  it 
done  in  two  months.  (D.  Krawchuk,  personal  communication,  February 
13,  2013) 


WBB  is  a  consulting  firm  that  provides  contracted  services  to  the 
government  and  private- sector  companies.  One  service  that  is  provided  and  used  by  the 
JPO  MRAP  was  consulting  provided  within  WBB’s  acquisition  management  function. 

As  part  of  our  customer  support,  we  have  developed  every  type  of 
program  document,  analysis,  and  briefing  required  by  governance, 
acquisition,  budgeting,  and  requirements  processes.  Because  of  our 
experience  and  current  involvement  at  all  levels  of  the  acquisition  and 
requirements  chains  of  command,  we  know  who  to  talk  to  and  how 
coordination  processes  work.  So  we  can  efficiently  help  program 
managers  successfully  navigate  through  the  acquisition  life  cycle. 
(Whitney,  Bradley  and  Brown,  Inc.,  n.d.) 

WBB  specializes  in  providing  assistance  to  programs  throughout 
the  entire  acquisition  life  cycle.  Additionally,  they  are  not  a  company  that  competes  for 
the  contract  to  produce  a  materiel  solution  for  an  acquisition  program. 

The  use  of  consultants  increased  the  efficiency  of  the  MCD.  Cycle 
times  were  reduced  for  the  development,  staffing  and  approval  of  the  document. 


109 


Additionally,  the  consultants  would  ensure  the  developed  MCD  would  meet  the  desired 
needs  of  all  involved  stakeholders.  Benefits  gained  from  using  consultants  whose  focus 
was  on  JROC  approval  during  the  JCIDS,  resulted  in  a  significantly  decreased  MCD 
approval  cycle  time  and  the  development  of  a  sound  requirements  document. 
Additionally,  this  supported  the  CBTDEV’s  efforts  of  their  MCDs  by  providing  an 
additional  advocate  that  assisted  in  the  JROC  approval. 

In  our  analysis,  essential  collaboration  and  maximizing  resources 
facilitates  efficiencies  in  cycle  time.  However,  this  technique  is  not  outlined  in 
regulations  or  policy.  It  falls  outside  the  scope  of  traditional  methods.  The  use  of 
contracted  consultants  for  the  assistance  of  writing  and  staffing  of  requirements 
documents  may  have  increased  the  efficiency,  but  it  does  not  provide  justification  for  a 
rating  of  excellent  since  it  is  not  adhere  to  policy  and  regulations. 

Nonetheless,  defining  the  requirements  up  front  reinforced  this 
initiative.  The  M-ATV  base  model  was  created  from  the  needs  of  the  warfighter.  The 
base  model  of  the  M-ATV  was  to  provide  a  lightweight  survivable  platform.  All  other 
requirements  were  not  KPPs  but  additional  modifications  that  may  have  enhanced  the 
platform.  The  M-ATV  was  built  capsule  first.  The  frame  and  engine  were  built  around 
the  capsule.  The  idea  was  to  preserve  those  who  were  in  the  vehicle.  Both  the 
requirements  authors  and  those  on  the  source  selection  board  focused  on  the  requirements 
to  meet  the  warfighter’s  needs.  Force  protection  and  survivability  were  the  priorities  in 
their  analysis.  The  M-ATV  was  the  approved  solution  and  vehicle  of  choice  in 
Afghanistan. 

The  base  model  M-ATV  was  built  upon  the  basics  of  commonality 
in  order  to  minimize  logistics  demands  and  maximize  sustainability.  Oshkosh  Defense 
had  already  provided  the  medium  tactical  vehicle  for  the  DoD.  They  utilized  many  of  the 
parts  and  products  that  were  already  in  the  DoD’s  supply  system. 

The  M-ATV  govemment-fumished  equipment  (GFE)  were  all 
existing  items  in  the  Army’s  inventory,  and  each  item  had  already  met  a  Technology 
Readiness  Level  (TRL)  of  nine  or  an  actual  application  of  the  technology  during  mission 


110 


operations  (TEC-SHS,  2008).  This  includes  using  the  system  under  operational  mission 
conditions.  The  GFE  only  had  to  be  integrated  on  the  M-ATV.  For  example,  wiring 
harness  lengths  and  human  factors  needed  to  be  considered  to  ensure  the  warfighter  could 
fit  in  the  M-ATV  and  still  operate  comfortably.  This  was  a  lesson  learned  from  the  PM 
HMMWV. 


/.  M-ATV  Better  Buying  Power  2.0  Effectiveness  Analysis 

(1)  Eliminate  Redundancy  Within  Warfighter  Portfolios 

Rating:  Average. 

The  requirements  were  well  defined  in  the  original  approved 
JUONS.  The  warfighter  asked  for  an  MRAP-like  vehicle  based  on  the  same  capabilities 
of  the  existing  MRAP  FoV.  However,  the  JUONS  did  require  SWAP  analysis.  The  GFE 
that  existed  on  all  other  MRAP  trucks  (such  as  the  Army’s  Force  XXI  Battle  Command 
Brigade  and  Below  [FBCB2],  radios,  jammers,  and  anti-IED  Rhinos,  and  SPARKS  II 
Mine  Roller)  became  standard  issue  with  the  M-ATV.  There  was  no  other  ground 
tactical  vehicle  that  matched  the  maneuverability  and  survivability  within  the 
warfighter’s  portfolio. 

Key  attributes — the  [  Services  did  do  a  better  job  of  laying  out  some  KPP 
type  things  for  in  that  JUONS.  So  not  that  they  were  all  realistic,  but  then 
we  worked  with  them  to  help  determine  that.  (M.  Minto,  personal 
communication,  February  13,  2013) 

This  determination  allowed  the  key  stakeholders  to  minimize  the 
redundancies  within  the  M-ATV ’s  portfolio. 

The  M-ATV  was  frontloaded  with  GFE  that  initially  provided  the 
warfighter  with  capabilities  that  were  commonly  provided  as  MTO&E.  Figure  29  shows 
all  the  requirements  by  Service  that  the  capabilities  documents  detailed. 
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Figure  29.  M-ATV  Government-Furnished  Equipment  Requirements  (From  A.  Ha,  personal 

communication,  April  13,  2013) 


New  technologies  were  introduced  at  the  same  time  the  first  M- 
ATV  was  coming  off  the  production  line.  Configuration  management  became  a  greater 
challenge  as  USFOR-A(U.S.  Forces-Afghanistan)  identified  the  M-ATV  as  the 
warfighter’s  vehicle  of  choice.  The  M-ATV  was  the  platform  that  filled  the  JUONS 
capability  gaps  that  enhanced  the  ability  for  warfighters  to  conduct  their  missions. 

Another  example  involved  the  Army  Medical  Department 
(AMEDD).  There  was  also  a  requirement  for  an  ambulance  variant  of  the  M-ATV.  The 
requirement  was  for  the  M-ATV  to  carry  seven  personnel:  one  driver,  one  truck 
commander,  one  medic,  three  walking  wounded  who  could  sit  up,  and  one  litter 
ambulatory  who  could  lie  down  on  a  stretcher.  The  M-ATV  would  need  a  device  to  lift  a 
stretcher  with  a  person  on  it.  Personnel  standing  on  the  ground  could  not  do  this  safely 
because  the  upward  reach  was  too  high.  The  PM  M-ATV  received  a  prototype  of  the 
ambulance  variant  and  began  testing.  The  M-ATV  failed  testing  with  horrible  results. 
The  M-ATV  ambulance  extended  the  cab  over  the  wheel  base  (A.  Ha,  personal 
communication,  April  13,  2013).  Extension  of  the  cab  of  the  base  model  M-ATV’s 
capsule  would  not  meet  the  survivability  KPP.  Explosion  impacts  over  the  rear  axle 
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caused  injuries  to  the  personnel  because  it  overextended  the  capabilities  of  the  original 
capsule.  An  effective  capsule  could  not  meet  the  needs  of  the  medical  community  for  an 
M-ATV  ambulance.  Nonetheless,  the  AMEDD  continued  to  push  the  requirement. 

Additional  studies  also  revealed  that  the  maneuver  units  in  sector 
were  not  taking  their  HMMWV  ambulances  on  patrols.  It  had  become  the  overwhelming 
necessity  to  air  MEDEVAC/CASEVAC  casualties  off  the  battlefield  as  this  was  the 
quickest  means  for  casualties  to  receive  medical  attention.  Air  assets  could  get  the 
casualty  to  the  required  level  of  care  in  a  more  expedited  manner.  MEDEVAC  pilots 
were  receiving  the  training  to  identify  the  nearest  level  of  care  for  casualties  within  their 
area  of  operation.  Ultimately,  the  JROC  identified  that  the  AMEDD ’s  requirement  could 
not  be  met  and  cancelled  the  requirement. 

The  CBTDEV  executed  due  diligence  in  their  roles  and  continued 
to  seek  out  new  solutions  for  non-validated  requirements.  The  CBTDEV  sought  existing 
systems  to  incorporate  into  the  M-TAV  platform  in  order  to  reduce  redundancy  across  the 
warfighter’s  portfolios.  These  requirements  were  often  outside  the  scope  of  the  JUONS 
and  the  CPD.  Without  JROC-approved  requirements,  the  PM  could  not  support 
initiatives  outside  the  scope  of  their  authorized  funding.  The  JPO  MRAP  could  not 
restrict  the  CBTDEV  from  conducting  their  mission  of  delivering  the  warfighter’s 
requirements  to  the  program.  However,  the  program  office  clearly  conveyed  to  the 
CBTDEV  that  additional  initiatives  could  not  be  executed  without  funding. 

The  JROC  continued  to  follow  through  with  the  outlined  process 
of  the  JCIDS  for  validation  of  new  emerging  requirements.  Nonetheless,  the  JUONS  that 
outlined  the  requirements  for  the  M-ATV  was  excellent.  The  CBTDEV  encompassed  the 
warfighter’s  needs  commensurate  to  the  current  technologies  being  used  in  OEF  at  the 
time  it  was  authored. 

(2)  Improve  Requirements  Definition  and  Prevent 

Requirements  Creep. 

Rating:  Poor 
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The  M-ATV  became  a  product  of  requirements  creep  as  its 
relevancy  in  theater  grew.  The  platform,  much  like  HMMWV,  became  the  vehicle  of 
choice  in  OEF.  The  M-ATV  was  the  32nd  variant  of  the  MRAP  (Kelley,  2012).  Initially, 
JPO  MRAP  had  the  ability  to  control  requirements  of  the  M-ATV  by  meeting  the  needs 
of  the  CPD. 

They  [CBTDEV]  did  do  a  better  job  there,  but  when  we  look  at  the  vehicle 
JUONS’  versus  some  of  the  other  JUONS’  that  we  received  for  widgets 
and  things  like  that,  some  of  the  things  that  tied  our  hands  and  didn’t  allow 
us  to  do  some  of  the  things  we  wanted  to  do  was  they  wrote  in  a  specific 
type  of  [material  specification]  not  a  capability,  but  a  specific  [desired 
material].  (M.  Minto,  personal  communication,  February  13,  2013) 

Specific  material  specifications  constrained  the  program  office  to 
effectively  analyze  multiple  materiel  solutions.  Exact  specifications  can  lead  to  situations 
of  requirements  creep.  For  the  M-ATV,  this  occurred  by  the  MCD  specifying  the  exact 
specification  instead  of  performance  requirements.  Projection  of  capabilities  allows  for 
adequate  planning  to  allow  the  materiel  solution  to  be  interoperable  with  other 
subsystems  that  may  be  added  to  the  materiel  solution  (Figure  30).  This  maximizes  the 
effectiveness  of  the  MCD. 

The  CBTDEV  and  The  JPO  MRAP  worked  hard  to  ensure  that  the 
requirements  were  clearly  stated  in  the  CPD  and  that  all  key  stakeholders  concurred  with 
the  requirements,  although  new  technologies  had  to  be  integrated  on  the  M-ATV  as  the 
warfighter  demanded  more  out  of  a  platform.  This  caused  further  demands  on  the  M- 
ATV  platform  to  be  the  warfighters’  tool  to  accomplish  their  missions.  Only  later  was  it 
revealed  that  the  M-ATV  also  had  its  downside  in  requirements.  This  became  a  burden 
to  the  program  office  once  the  M-ATV  entered  Afghanistan.  Requirements  creep  did 
occur  as  unanticipated  initiatives  needed  to  be  integrated  on  the  M-ATV. 

The  initial  FRIP  of  the  M-ATV  met  the  requirements  outlined  by 
the  CBTDEV’s  MCD  and  collaborated  by  the  program  office,  as  a  standalone  materiel 
solution.  The  M-ATV  would  later  have  additional  FRIPs  to  build  platforms  for  the 
warfighter  and  the  Special  Operations  Command’s  needs.  The  JPO  MRAP  and  the 
CBTDEV  had  projected  additional  power  requirements  for  the  M-ATV  based  upon 
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lessons  learned  from  past  MRAP  vehicles  and  their  SWAP  analysis.  Technology 
advancements  had  to  be  integrated.  However,  other  C4ISR  program  offices  also  required 
that  their  technologies  be  integrated  on  the  M-ATV.  Modifications  to  the  base  M-ATV 
platform  had  to  accommodate  electromagnetic  compatibility/electromagnetic  interference 
(EMC/EMI)  testing  for  eight  separate  C4ISR  end  items  with  multiple  wiring  harnesses, 
antennas,  and  other  hardware  while  still  maintaining  the  integrity  of  the  hull  of  the 
vehicle.  Figure  30  depicts  the  base  M-ATV  produced  from  the  CPD  to  the  C4ISR  suite 
modification  that  support  additional  technology  initiatives  from  other  program  offices. 


Figure  30.  M-ATV  Characteristics  (After  A.  H.  Ha,  personal  communication,  April  13, 

2013) 


Once  fielded  in  Afghanistan,  requirements  creep  became  the  bane 
of  M-ATV  and  its  CPD.  Many  unforeseen  requirements  arose  as  the  M-ATV  began  to 
flood  the  Afghanistan  battle  space.  An  example  of  this  is  the  B -Pillar  Handle.  The  B- 
Pillar  handle  was  made  for  military  personnel  to  easily  climb  up  into  the  vehicle  while 
carrying  the  weight  of  battle  equipment  (Oshkosh  Defense,  2010).  Neither  the  PM  M- 
ATV  nor  the  CBTDEV  could  foresee  that  soldiers  would  use  the  horizontal  handle  as  a 
step  to  reach  the  top  of  the  truck  in  order  to  enter  the  turret  or  to  clear  the  OGPK  weapons 
system.  Even  after  the  PM  M-ATV  painted  a  template  with  the  statement,  “DO  NOT 
STEP,”  underneath  the  handle,  the  warfighter  continued  to  do  so.  Once  the  handle  broke 
off,  the  soldiers  used  the  frame  of  the  vehicle  to  enter  the  M-ATV.  A  soldier  who  was 
unaware  that  another  soldier’s  hand  was  on  the  frame  would  close  the  ballistic  door  on 
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the  other’s  hand  and  break  the  hand  (Oshkosh  Defense,  2010).  The  PM  M-ATV 
underwent  a  $3  million  modification  for  a  vertical  handle  that  could  not  be  used  as  a  step, 
even  though  this  issue  could  have  been  resolved  by  reinforced  training. 

Furthermore,  combat  commanders  made  changes  in  theater  to  meet 
their  needs.  At  the  initial  inception  of  the  M-ATV,  the  combat  commanders  in  OEF 
required  a  mixture  of  OGPK  turrets  and  remote  weapons  station  (RWS)  turrets.  The 
initial  capability  request  was  for  a  1:1  ratio  of  OGPK  to  RWS  (D.  Krawchuk,  personal 
communication,  April  13,  2013).  The  JPO  MRAP  built  the  OGPK  M-ATVs  to  the 
established  requirement  and  quickly  deployed  the  vehicles  to  theater  per  the  guidance  of 
OEF-A  (Operation  Enduring  Freedom  -  Afganistan).  After  M-ATVs  with  RWSs  had 
already  begun  fielding,  the  new  commander  demanded  a  change  in  the  requirement  to  a 
3:1  ratio  (D.  Krawchuk,  personal  communication,  April  13,  2013).  The  new  ratio 
requirement  was  approved  by  the  JROC,  and  the  JPO  MRAP  had  to  comply. 

Threat-based  requirements  evolved  as  RPGs  were  continually 
becoming  an  issue  in  OEF.  The  M-ATV  armor  provided  the  capability  against  the  initial 
type  of  RPGs  required.  However,  the  enemy  advanced  the  threat,  and  RPG  nets  had  to  be 
provided  for  the  M-ATV.  Bar-armor  already  existed  on  the  Stryker  vehicle  but  would 
increase  the  weight  of  the  M-ATV  if  integrated  on  that  vehicle.  The  M-ATV  was 
outfitted  with  a  lighter  solution  in  order  to  stay  within  the  weight  KPP.  The  IED  threat 
also  increased  as  the  more  survivable  M-ATVs  were  produced  and  deployed  to  OEF  from 
an  increase  in  production  numbers  approved  by  the  JROC  (Director,  Operational  Test  and 
Evaluation,  2009).  The  M-ATV  had  met  its  threshold  solution  during  blast  testing 
(Director,  Operational  Test  and  Evaluation,  2012).  Yet,  the  enemy  countered  that 
solution.  The  JPO  MRAP  had  to  integrate  an  Underbelly  Improvement  Kit  (UIK)  in 
order  to  provide  a  more  survivable  platform  for  the  warfighter  (Director,  Operational  Test 
and  Evaluation,  2012). 

The  SPARKS  II  Mine  Roller  was  another  issue  that  evolved  from 

the  combat  commanders’  selection  of  the  M-ATV  as  the  vehicle  of  choice  and  from 

threat-based  requirements.  Originally,  the  mine  roller  was  used  on  route  clearance 

vehicles.  The  requirement  changed  so  that  all  M-ATVs  would  have  a  SPARKS  II  Mine 
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Roller  adapter  bracket  (Product  Manager  Close  Combat  Systems  [PM  CCS],  n.d.).  The 
SPARKS  II  began  fielding  after  the  M-ATV.  The  SPARKS  II  would  kick  up  debris  into 
the  radiator,  causing  the  M-ATV  to  overheat.  It  became  a  question  of  whether  this  was  a 
PM  IED  Defeat  issue  or  a  PM  M-ATV  issue.  More  protection  for  the  radiator  required 
major  changes  to  the  vehicle,  post-production.  This  issue  was  resolved  by  adding  mud 
flaps  on  the  SPARKS  II;  however,  the  PM  M-ATV  invested  a  great  deal  of  engineering 
and  testing  to  assist  in  resolving  this  issue. 

These  are  just  a  couple  of  examples  of  the  requirements  creep  that 
occurred  on  the  M-ATV.  Figure  31  captures  several  other  examples  of  requirements 
creep. 


Figure  31.  M-ATV  Retrofits  (From  A.  Ha,  personal  communication,  April  13,  2013) 

There  is  a  direct  correlation  between  the  necessities  to  align 
simultaneous  materiel  solution  initiatives  and  clearly  defined  requirements  in  order  to 
alleviate  requirements  creep  from  occurring.  The  requirements  outlined  in  the 
capabilities  documents  must  consider  the  overall  ongoing  programs’  initiatives.  The 
JUONS  outlined  requirements  at  that  time,  although  new  technologies  had  to  be 
integrated  on  the  M-ATV  as  the  warfighter  demanded  more  out  of  a  platform.  This 
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caused  further  demands  on  the  M-ATV  platform  to  be  the  warfighters’  tool  to  accomplish 
their  missions. 

Furthermore,  DOTMLPF  must  constantly  considered  by  the 
CBTDEV  when  presented  with  new  requirements.  A  great  deal  of  cost  could  have  been 
avoided  if  training  had  been  implemented  in  safety  of  use  versus  creating  the  B -Pillar 
Handle  materiel  modification. 

g.  M-ATV  Efficiency  and  Effectiveness  Analysis 
Figure  32  depicts  our  overall  rating  of  the  M-ATV’s  MCDs. 


BBP  2.0  Principles  and  Initiatives 
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Figure  32.  M-ATV  Overall  Rating  Scorecard 


Overall  Score 
Efficiency:  2  x  Average 
Effectiveness:  1  x  Poor,  1  x  Average 
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Figure  33  depicts  our  overall  rating  of  the  M-ATV’s  MCDs 


Figure  33.  M-ATV  Efficiency  and  Effectiveness  Analysis 
(After  Griiter  &  Boerendans,  2013) 

Overall  Rating  (Results) 

Efficiency:  Average 
Effectiveness:  Poor  -  Average 

The  M-ATV  receives  an  efficiency  rating  of  average.  The  requirements 
outlined  in  CPD  V2  fulfilled  the  needs  of  the  warfighter  to  produce  the  M-ATV.  CPD 
V2  by  a  contracted  consultant  was  staffed  due  to  the  urgent  and  compelling  need  for  the 
M-ATV  in  OED.  However,  the  use  of  contracted  consultant  may  have  decreased  the 
cycle-time;  nonetheless,  this  method  is  outside  the  realm  of  regulations  and  cannot 
support  a  higher  score. 
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Additionally,  urgent  needs  and  rapid  acquisition  pushed  for  the  expedited 
production  of  the  M-ATV.  The  M-ATV  platform  was  extremely  efficient  in  meeting  the 
initial  capability  gaps  for  the  warfighter.  However,  well  defined  requirements  lost  some 
efficiency  as  new  JUONSs  emerged  and  desired  capabilities  grew.  Additionally,  cycle 
times  maximized  efficiency  due  to  the  urgent  and  compelling  needs  for  the  M-ATV. 

The  M-ATV  receives  a  rating  of  poor-average  for  effectiveness.  The 
CPD  V2  requirements  were  outlined  for  capabilities  with  existing  technologies  that  had 
reached  TRL  nine.  This  ensured  that  the  GFE  added  onto  the  vehicle  was  at  the  highest 
TRL  level  to  prevent  M-ATVs  from  having  different  versions  or  upgrades  of  GFE.  The 
possession  of  different  versions  of  GFE  creates  additional  M-ATV  variants  and  increases 
redundancy  in  the  warfighter  portfolio.  Thus,  MCDs  increased  effectiveness  by 
minimalizing  redundancy.  However,  requirements  creep  became  an  obstacle  for  the 
program  as  the  M-ATV  became  the  vehicle  of  choice  in  Afghanistan.  Additionally,  it 
became  the  common  practice  for  new  technologies  to  be  integrated  on  the  M-ATV.  The 
M-ATV  CPD  became  less  relevant  as  every  other  program  came  to  the  realization  that 
relevancy  would  be  required  for  integration  onto  the  M-ATV.  Furthermore,  the  program 
was  comprised  of  a  workforce  of  several  generations  and  varying  levels  of  experience, 
which  constrained  the  program’s  effectiveness. 

3.  Joint  Light  Tactical  Vehicle  (JLTV) 

The  below  images,  in  Figure  34,  are  of  the  three  competitive  prototypes  for  the 

JFTV. 


Figure  34.  Potential  JFTV  Vehicles  by  AM  General,  Oshkosh  Corp.,  and  Fockheed  Martin 

(From  GAO,  2013,  p.  85) 
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a. 


Mission 


“The  JLTV  program  creates  a  common  family  of  vehicles  consisting  of 
the  Combat  Tactical  Vehicle  (CTV)  and  Combat  Support  Vehicle  (CSV).  The  CTV  has 
multiple  combat  mission  role  variants  while  the  CSV  has  the  ability  to  be  employed  as 
either  a  utility  vehicle  or  shelter  carrier”  (PM  JLTV,  2013). 

b.  Vision 

“JLTV — Balancing  the  iron  triangle  (Protection,  Performance  &  Payload) 
for  the  joint  forces”  (PM  JLTV,  2013). 

c.  Focus 

“The  Joint  Light  Tactical  Vehicle  (JLTV)  Family  of  Vehicles  (FoV)  is  a 
Joint  Army  and  Marine  Corps  program  that  provides  vehicles,  along  with  companion 
trailers,  capable  of  performing  multiple  mission  roles  while  providing  protected, 
sustained,  and  networked  mobility  for  personnel  and  payloads  across  the  full  spectrum  of 
military  operations”  (PM  JLTV,  2013). 

d.  JLTV  Background 

The  JLTV  is  a  major  acquisition  ACAT  ID  program  facilitated  by  the 

Army  and  Marine  Corps.  The  JLTV  is  the  best  materiel  solution  to  meet  the  prescribed 
capability  gaps  outlined  primarily  by  the  Anny  and  Marine  Corps’  CBTDEV  AoA  report. 
The  capability  gap  that  is  unfulfilled  by  the  current  system,  the  HMMWV,  is  explained 
below. 

Based  upon  the  Technology  Development  phase  results,  the  Analysis  of 
Alternatives  concluded  that  the  JLTV  program  is  the  best  option  to  fulfill 
the  capability  gaps.  The  Capabilities  Development  Document  requires  the 
JLTV  program  to  develop  two  mission  role  variants  (MRVs),  a  two  seat 
MRV  and  a  four  seat  MRV,  to  regain  transportability  and  restore  balance 
in  the  “Iron  Triangle”  of  protection,  payload  and  performance.  (Hepner, 

2011,  p.  1) 
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Additionally,  the  identified  capability  gap  requires  the  JLTV  system  to 
augment  a  family  of  systems  to  support  ground  tactical  operations.  Augmentation  of 
existing  systems  led  the  Army  to  issue  an  EMD  RFP  for  at  least  20,000  JLTVs  and  5,500 
vehicles  for  the  Marines  (Feickert,  2013). 

In  2006,  the  JPO  JFTV  was  established.  Approval  of  the  program  also 
identified  the  Army  as  the  lead  proponent  of  the  program,  which  falls  under  the  Army’s 
PEO  Combat  Support  and  Combat  Service  Support  (CS&CSS).  The  Marines  have  the 
JFTV  program  under  the  leadership  of  PEO  Fand  Systems  (FS).  The  Under  Secretary  of 
Defense  John  J.  Young,  Jr.,  approved  the  JFTV  program  to  move  into  the  technology 
development  phase  (JROC,  2007a).  The  current  timeline  for  the  program  is  shown  in 
Figure  35. 
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Figure  35.  Current  JFTV  Timeline  (From  GAO,  2013,  p.  85) 


The  support  vehicle  is  the  two-seat  variant  CSV.  The  combat  vehicle  is 
the  four-seat  variant  CTV.  The  two-seat  variant  is  a  one  base  vehicle  platform,  also 
known  as  the  Utility  (UTF)  platform.  The  two-seat  variant  has  a  payload  capacity  of 
5,100  pounds  (Feickert,  2013).  The  four-seat  variant  has  a  payload  of  3,500  pounds 
(Feickert,  2013).  The  four-seat  variant  has  two  base  vehicle  platforms  comprised  of  the 
Close  Combat  Weapons  Carrier  (CCWC)  and  the  General  Purpose  (GP)  platform.  All 
platforms  are  configured  through  the  installation  of  mission  packages.  Mission  packages 
include  the  UTF,  GP,  Heavy  Guns  Carrier  (HGC),  and  CCWC.  Figure  36  shows  the 
flowchart  for  the  different  JFTV  variants,  and  Table  5  shows  the  relation  of  the 
anticipated  mission  roles  and  the  variants  to  be  used  for  that  particular  mission  role. 
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Figure  36.  JLTV  Variants  (From  PM  JLTV,  2013) 
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Table  5.  Joint  Light  Weight  Tactical  Vehicle  Configurations 
(From  JROC,  2007b,  Appendix:  Configurations,  p.  1) 


Mission  Role 

Mission  Role  Variant 
(MRV)  Configurations 

Mission  Packages 

Move  Small  Units,  Unit 
Leaders,  and  Staff 

Combat  Tactical  Vehicle 
(CTV) 

General  Purpose  (GP)  (4  seats) 

Move  Infantry  Weapons 
and  Security  Forces 

Heavy  Guns  Carrier  (HGC)  (4  seats  ) 

(Wpns  Co,  MP,  Mounted  Patrol;  Convoy  Escort) 

Move  Anti-Armor 

Weapons 

Close  Combat  Weapons  Carrier  (CCWC) 

TOW/Saber  Carrier  (4  seats) 

Carry  Light  Cargo;  Move 
Combat  Support 

Elements;  Carry  Light 
and  Standard  Shelters 

Combat  Support  Vehicle 
(CSV) 

Utility/Prime  Mover  (2  Seats) 

(105-mm  Howitzer,  Q-36  Radar); 

Shelter  Carrier  (2  Seats) 

(Standard  Shelters — Maintenance, 

Communications) 
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The  JLTV  program  faced  setbacks  in  May  2011.  Discoveries  made  during 
the  technology  development  phase  showed  some  requirements  to  be  unattainable.  The 
JLTV  was  unable  to  achieve  transportability  and  protection  level  requirements  (GAO, 
2013).  These  unachievable  requirements  led  the  program  to  the  decision  of  canceling  the 
special  purpose  and  command  and  control  variants  from  the  FoV  (GAO,  2013).  The 
JLTV  attempted  to  move  into  MS  B  but  was  denied  until  the  program  could  effectively 
show  a  better  technology  development  strategy.  The  JPO  JLTV  was  forced  to  review  the 
requirements  and  ensure  that  the  technologies  of  the  platform  were  mature  enough  to 
move  into  MS  B. 

Additionally,  the  program  had  to  overcome  the  inevitable  obstacles  of 
future  funding  constraints  and  lack  of  technical  maturity  to  support  the  capabilities  of 
these  platforms,  and  it  had  to  better  define  the  requirements  and  their  associated  metrics 
to  validate  the  materiel  solution  during  operational  testing.  Better  definition  of  the 
requirements  came  through  collaboration  between  the  CBTDEV  and  the  JPO  JLTV  to 
develop  trade-offs  within  the  threshold  and  objective  values  for  the  requirements.  The 
JPO  JLTV  recognized  that  it  would  have  to  reform  its  acquisition  strategy  (see  Figure  37) 
if  it  was  to  remain  a  DoD  program  of  record.  Additionally,  the  JPO  JLTV  and  the 
CBTDEV  came  together  to  better  understand  whether  the  requirements  written  in  the 
ICD  and  CDD  were  efficient  if  the  JLTV  was  ever  to  reach  production. 
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The  JLTV  is  a  materiel  solution  that  existed  after  the  inception  of  the 
JCIDS  and  has  followed  the  process  outlined  in  JCIDS.  The  JLTV  life  cycle  continues 
through  the  modifications  in  the  JCIDS.  The  last  RGP  instruction  for  the  JCIDS  came 
into  effect  in  June  2012.  The  JPO  JLTV  uses  the  JCIDS  documents  to  guide  their 
program.  The  ICD  and  CDD  capabilities  documents  have  been  used  in  our  analysis.  The 
program  has  yet  to  reach  the  acquisition  life  cycle  phase  requiring  the  CPD. 

Identified  gaps  associated  with  the  CBTDEV’s  capability-based 
assessment,  in  addition  to  protection,  payload  and  performance,  are  found  in  the  ICD. 

The  JLTV  family  of  vehicles  (FoV)  is  intended  to  fill  capability  gaps 
identified  by  the  combat  developer’s  functional-needs  analysis.  These  capability  gaps  are 
defined  as: 

1  -  inability  to  move  mounted  infantry/combat  arms  forces  via 
ground 

2  -  inability  to  move  mounted  combat  support  (CS)  forces  via 
ground 

3  -  inability  to  move  mounted  combat  service  support  (CSS)  forces 
via  ground 

4  -  inability  to  move  light  infantry  (airbome/air  assault)  via  ground 

5  -  inability  to  move  long-range  reconnaissance  (undetected)  via 
ground.  (Survivability/Lethality  Analysis  Directorate  [SLAD], 

2013) 

The  JLTV’s  ICD  established  the  initial  capability  gap  for  the  vehicle. 
These  requirements  for  the  capability  gap  differ  from  other  vehicles  in  the  Army’s 
portfolio.  JLTV’s  ICD  requirements  are  call  for  a  vehicle  to  transport  troops,  assist  with 
CS  and  CSS  forces,  and  provide  a  lightweight  vehicle  for  the  light  infantry  BCTs.  This  is 
different  from  the  Bradley  fighting  vehicle  with  a  sole  use  within  the  heavy  BCTs  and  for 
tactical  combat  operations  only.  Bradley  fighting  vehicles  are  not  used  with  any  CS  or 
CSS  operations  or  personnel.  Furthermore,  the  JLTV’s  identified  capabilities  gaps 
transitioned  into  requirements  during  the  process  of  developing  the  CDD.  Transition 
from  a  broad  scope  of  an  identified  capability  gap  to  the  specific  requirements  was 
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accomplished  through  close  coordination  between  stakeholders,  specifically  the  product 
office  and  the  CBTDEV. 


Upon  the  JROC’s  validation  and  approval  of  the  capabilities  documents,  the 
program  was  able  to  enter  the  first  two  phases  of  the  acquisition  life  cycle.  Additional 
resources  were  used  to  analyze  the  validity  of  the  capability  gaps  and  requirements.  The 
RAND  Corporation  examined,  compared,  and  analyzed  the  capability  gaps  and 
requirements  between  the  ICD  and  CDD  to  ensure  that  overlap  between  new  and  existing 
systems  would  not  occur  (Kelly,  Peters,  Landree,  Moore,  Steeb,  &  Martin,  2011). 

RAND’s  National  Defense  Research  Institute  was  asked  to  conduct  the 
study  and,  specifically,  to  provide  a  detailed  discussion  of  requirements 
and  capability  needs,  identify  capability  gaps  for  vehicles,  identify  critical 
technology  elements  or  integration  risks  associated  with  particular 
categories  of  vehicles  and  specific  missions,  and  recommend  actions  to 
address  the  identified  capability  gaps. 

The  researchers  found  no  fundamental  flaws  in  the  requirements 
development  processes  for  the  vehicles  considered.  However,  predicting 
future  threats  over  the  expected  life  spans  of  vehicles  now  in  production  is 
very  difficult,  and  choices  must  be  made  and  risk  accepted  due  to  the 
impossibility  of  designing  vehicles  that  are  optimal  for  ah  future  threats. 

(Kelly  et  al.,  2011,  p.  1) 

RAND  was  able  to  show  the  Army’s  identification  of  a  capability  gap  and  the  Army’s 
analysis  was  correct  for  determining  the  need  of  a  materiel  solution. 

e.  JLTV  Better  Buying  Power  2.0  Efficiency  Analysis 

(1)  Build  Stronger  Partnerships  With  the  Requirements 
Community  to  Control  Costs. 

Rating:  Excellent 

The  JLTV  ICD  outlines  many  different  requirements  that  are 
expected  from  the  materiel  solution.  Some  of  the  requirements  could  not  be  met  without 
neglecting  other  requirements.  During  the  testing  period,  May  2010  to  June  2011,  the 
Army  and  Marine  Corps  determined  that  the  vehicle’s  original  transportability  and 
survivability  requirements  could  not  be  met  (GAO,  2012).  Efforts  taken  to  meet  the 
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requirements  and  reduce  the  weight  of  the  vehicle  would  drastically  take  away  from  the 
survivability  of  the  platform  (GAO,  2012).  Coordination  and  trade-offs  had  to  be  made. 

The  [SJervices  have  relaxed  part  of  the  requirement  to  transport  the 
vehicle  by  helicopter  at  high  altitude  and  at  certain  temperatures,  which 
will  permit  a  heavier  vehicle  to  be  transported.  As  a  result  of  the 
requirements  changes,  the  Army  and  Marine  Corps  will  shift  some 
missions  intended  for  JLTV  to  the  HMMWV.  (GAO,  2012,  p.  149) 

JLTV  is  a  program  that  has  demonstrated  how  different 
stakeholders  are  able  to  work  together  to  refine  or  even  eliminate  requirements  that  are 
determined  to  be  unattainable  or  unfeasible.  This  is  the  essence  of  trade-off  between  the 
CBTDEV  and  the  program  office.  A  decrease  in  efficiency  is  the  outcome  of  attempting 
to  achieve  unattainable  or  unfeasible  requirements  by  requiring  more  time,  money,  and 
resources.  The  JPO  JLTV  identified  a  means  to  overcome  the  challenges  of  its 
requirements  while  minimizing  the  loss  of  the  prescribed  capabilities.  The  following 
quotes  from  COL  Dave  Bassett,  serving  as  the  JPM  for  JLTV,  show  how  the  program 
was  able  to  closely  coordinate  between  the  acquisition  and  user  communities. 

In  this  case,  we  had  to  collaborate  together  to  make  the  final  adjustments 
to  the  program  so  that  the  acquisition  strategy,  the  budget,  the 
requirements  and  technology  were  in  alignment. 

So — and  having  the  key  leaders  on  both  the  requirements  and  the 
acquisition  side  and  the  resource  side  go  down  that  path  together  and  make 
those  decisions  understanding  when  a  decision  on  the  requirements  side  is 
going  to  have  a  direct  impact — it  is  not  even  a  second  order  effect,  a  direct 
impact  on  the  acquisition  strategy  and  path  forward  to  actually  produce 
that  system,  (personal  communication,  Lebruary  12,  2013) 

The  ability  to  work  together  between  the  program  office  and  the 
CBTDEV  was  essential  in  establishing  the  program’s  acquisition  baseline  and 
maximizing  efficiencies  to  continue  to  achieve  the  desired  capabilities.  The  collaboration 
between  the  communities  led  to  the  ability  to  remove  capabilities  that  may  generate 
higher  risk  and  cause  timelines  to  extend  longer  than  desired.  Prevention  of  risk  and 
reduction  in  time  in  capabilities  trade-off  afforded  greater  efficiency.  “I  was  able  to  work 
with  the  user  community  to  pull  out  [requirements]  in  a  way  that  was  mutually 
supportive”  (D.  Bassett,  personal  communication,  Lebruary  12,  2013).  A  clear  example 
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of  the  program  officer  for  the  JLTV  working  closely  together  with  the  requirements 
community  is  seen  from  the  trade-off  accepted  for  not  being  able  to  meet  the  weight 
requirement  for  the  vehicle. 

The  program’s  involvement  with  the  MCDs  assisted  in  the  ability 
to  effectively  complete  the  capabilities  documents  with  the  CBTDEV.  This  had  to  be 
done  in  order  to  ensure  all  stakeholders  concurred  in  the  final  MCDs  and  maximize 
effectiveness. 

I  think  that  in  the  development  of  that  draft  CDD  it  can’t  be  TRADOC  in 
isolation.  It  has  to  be  a  collaborative  process.  However,  in  that  draft  CDD 
and  in  any  technology  development  phase,  there  may  be  some 
requirements  that  you  deliberately  stretch  for.  So  you  know  maybe  you 
want  to  use  your  technology  development  phase  to  really  understand  the 
left  and  right  limits  and  cost  of  power  generation.  So  it  was  okay  that  the 
TD  vehicles  on  JLTV  pursued  a  substantially  higher  power  generation 
requirement  than  we  ended  up  [with]  in  our  CDD.  (D.  Bassett,  personal 
communication,  February  12,  2013) 

This  collaboration  increased  the  efficiency  of  the  workforce.  By 
doing  so,  the  workforce  increased  their  experience  not  only  with  the  RGP  but  also  with 
the  CBTDEV.  While  collaboration  is  essential  in  the  development  of  MCDs,  the 
CBTDEV  must  ensure  they  continue  to  develop  those  involved  in  RGP  and  not  allow  the 
acquisition  workforce  to  surpass  the  CBTDEV’s  experience. 

The  JPO  JLTV  is  able  to  progress  towards  the  production  and 
deployment  phase  of  the  acquisition  life  cycle  from  its  MCDs.  Personnel  in  the  program 
office  are  able  to  build  the  program’s  RFP  to  clearly  outline  what  is  accepted  of  the 
potential  contractors  by  building  performance  specifications  from  the  requirements  in  the 
MCDs.  An  excerpt  from  the  draft  executive  summary  of  the  request  for  proposal  shows 
the  program’s  insight  to  prevent  untested  technologies  and  unproven  designs. 

The  JLTV  acquisition  strategy  pre-supposes  successful  achievement  of 
EMD  testing  and  appropriate  risk  mitigation  to  achieve  a  Milestone  C 
decision.  Therefore,  the  Production  Phase  test  profile  is  expected  to  be 
scaled  to  mitigate  the  remaining  post  Milestone  C  risks  and  complete 
mandated  testing,  and  will  not  duplicate  the  extensive  EMD  testing. 
Accordingly,  during  the  competition  for  the  single  award  of  the 
Production  and  Deployment  Phase  Contract,  any  offeror  proposing  JLTV 
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vehicle  solutions  reflecting  untested  and/or  un-validated  designs,  or 
only  partially  tested  designs,  will  be  evaluated  with  higher  risk.  (Hepner, 

2011,  p.  2) 

The  JPO  JLTV’s  RFP  for  a  production  and  deployment  phase 
contract  provides  instructions  to  potential  competitors  that  that  a  higher  risk  is 
automatically  going  to  be  assumed  for  untested  and  un-validated  vehicle  designs.  This 
creates  a  measurement  within  the  contract  to  provide  higher  scores  to  companies  with  a 
validated  design.  Movement  in  this  direction  creates  greater  efficiencies  towards  the 
materiel  solution  by  reducing  contractors  that  are  not  fully  capable  of  delivering  the 
desired  system.  Additionally,  this  serves  as  the  program’s  means  to  keep  the  program 
and  contractors  on  track  for  capabilities  that  have  already  been  agreed  upon  with  the  user 
community  and  that  are  capable  of  being  met  with  mature  technologies. 

The  JLTV’s  MCDs  has  been  able  to  clearly  define  the 
requirements  for  the  defense  industry  to  better  understand  what  is  needed  for  prototyping. 
The  JPO  JLTV  continues  to  keep  the  defense  industry  abreast  of  the  current  status  of  the 
program.  The  program  has  conducted  meetings  and  industry  days  to  answer  all  questions 
that  may  not  be  fully  understood  in  the  MCDs  and  has  created  a  website  for  industry 
exchange  (Petermann  &  Garza,  2010).  The  JPO  JLTV  has  embraced  industry  as  a 
stakeholder  and  network  partner  in  its  endeavor  to  produce  a  materiel  solution.  The  JPO 
JLTV  understands  the  importance  of  the  requirements  provided  by  the  CBTDEV  and 
recognizes  that  the  survivability  of  its  program  does  not  stop  in  the  program  office.  The 
JPO  JLTV  brings  industry  into  the  loop  in  order  to  maximize  the  efficiency  of  the 
requirements. 

(2)  Reduce  Cycle  Times  While  Ensuring  Sound  Investment 

Decisions. 

Rating:  Average 

The  JLTV’s  MCDs  attempt  to  efficiently  reduce  cycle  times. 
These  documents  are  one  of  many  factors  that  drive  the  program’s  acquisition  strategy. 
Industry  has  to  consider  not  only  what  the  materiel  solution  needs  to  be  but  also  how  to 
employ  its  best  practices  in  production  and  sustainment  to  drive  down  costs.  The  JPO 
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JLTV  has  placed  a  great  deal  of  reliance  on  the  defense  industry  to  meet  the  needs  of 
many  capability  gaps.  By  doing  so,  the  program  attempted  to  minimize  the  technology 
development  phase  but  went  back  to  the  TD  phase  upon  receiving  guidance  for 
competitive  prototyping. 

The  CDD  was  approved  and  facilitated  an  avenue  for  efficient 
competitive  prototyping.  Competitive  prototyping  is  the  ability  to  carry  multiple  vendors 
into  the  EMD  phase  for  the  purpose  of  having  prototypes  that  have  capabilities  that  may 
be  compared  against  each  other.  This  would  reduce  the  costs  associated  with  developing 
new  or  untested  technology  in  the  TD  and  EMD  phases  of  the  program.  Going  through 
this  effort  creates  competition  within  the  industries  and  potentially  leads  to  a  product  that 
has  greater  capabilities  and  a  lower  price  to  the  government. 

Additionally,  the  focus  has  shifted  towards  utilizing  mature 
technology  and  vehicle  designs. 

In  February  2011,  the  JLTV  Program  Office  announced  the  award  of  the 
EMD  contract  would  be  delayed  until  January  or  February  2012  because 
the  Army  changed  requirements  for  the  JLTV  to  have  the  same  level  of 
under  body  protection  as  the  Mine-Resistant,  Ambush-Protected  All- 
Terrain  Vehicle  (M-ATV).  DOD  had  planned  to  award  two  contracts  for 
the  EMD  phase,  which  was  scheduled  to  last  24  months,  but  instead  opted 
for  a  48-month-long  EMD  phase  before  awarding  Production  and 
Deployment  contracts  in  the  second  quarter  of  FY2016.  In  addition,  the 
Category  B  variant  was  eliminated  because  it  proved  to  be  too  heavy  to 
meet  the  required  weight  of  approximately  15,639  pounds  to  make  it 
transportable  by  Army  CH-47F  and  Marine  Corps  CH-53K  helicopters. 

Now  there  will  be  two  variants — a  Combat  Tactical  Vehicle  (CTV),  which 
can  transport  four  passengers  and  carry  3,500  pounds,  and  a  Combat 
Support  Vehicle  (CSV),  which  can  transport  two  passengers  and  carry 
5,100  pounds.  (Feickert,  2013,  p.  3) 

Although  the  program  had  to  restart  the  second  phase  of  the  DAS, 
the  JPO  JLTV  recognized  that  they  must  maximize  efficiency  in  their  timeline  in  order  to 
complete  the  EMD  phase.  Some  unrealistic  requirements  that  the  CBTDEV  and  the  JPO 
JLTV  concurred  that  some  requirements  were  unrealistic  and  removed  them  from  the 
CDD..  Removal  of  these  requirements  and  expanding  the  EMD  phase  can  produce  cost 
savings.  Cost  savings  would  occur  up  front  with  removing  requirements  and  later  on  in 
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the  program  by  ensuring  that  a  mature  and  validated  design  is  ready  before  entering  into 
production  and  deployment.  However,  the  extended  EMD  phase  creates  a  delay  within 
the  program  and  displays  signs  of  inefficiency  by  requiring  more  time  within  the  specific 
phase.  Vehicle  programs  constantly  struggle  with  trying  to  reach  threshold  values  for 
weight.  The  removal  of  that  requirement  creates  greater  efficiency,  saves  the  program 
money,  and  prevents  delays  that  could  be  created  when  trying  to  reach  weight  thresholds 
established  within  the  requirement. 

The  JLTV  program  also  analyzed  the  designs  of  similar  programs. 
Observations  of  these  other  programs  provided  the  necessary  insight  to  manage 
expectations  in  regards  to  timelines  and  respect  to  the  development  and  production  of  a 
vehicle.  In  addition,  risks  that  occurred  within  the  other  programs  could  be  anticipated 
and  mitigated  on  the  JLTV.  “We  had  seen  those  designs  evolve  over  time  largely 
because  of  the  Army’s  investment  in  [MRAPs]”  (D.  Bassett,  personal  communication, 
February  12,  2013). 

The  JLTV  program  is  able  to  take  lessons  learned  from  similar 
vehicle  programs  and  apply  the  corrective  actions  before  risks  or  issues  arise.  These 
identified  preemptive  actions  could  possibly  save  money  and  time  because  deficiencies 
would  not  have  to  be  corrected.  Moreover,  new  processes  would  not  have  to  be 
developed  because  best  practices  have  already  been  established  and  proven  to  work  in 
other  programs.  The  JPO  JLTV’s  attempt  to  not  repeat  the  mistakes  of  the  past  has 
allowed  for  greater  efficiency  in  the  program  to  meet  the  requirements  and  provide  a 
materiel  solution. 

The  JPO  JLTV  went  a  step  further  with  multiple  contractors  and  prototypes. 

“We  have  all  the  data  we  need  to  make  the  right  decision,”  he  [Kevin 
Fahey,  PEO  for  CS  &  CSS  Vehicles]  said.  “Based  on  that  data  we  came 
up  with  a  wonderful  acquisition  strategy  for  [moving  through]  EMD  and 
into  production.”  (Gourley,  2013,  p.  40) 

Fahey  reinforced  the  process  that  is  being  used  in  the  JLTV  program  office  to 
develop  a  product  with  minimal  cost  and  reduced  cycle  time.  Yet,  the  opposite  usually 
occurs  when  trying  to  reach  capabilities  in  the  MCDs  that  are  unfeasible  and  unrealistic. 


132 


The  JLTV  program  also  has  pursued  mature  designs  and 
technology  that  would  decrease  production  time  and  resources.  Working  to  meet  mature 
designs  and  technology  and  reducing  cycle  time  yields  a  program  to  make  better  sound 
investments.  The  JLTV  program  learned  from  the  shortfalls  in  their  past.  The  program 
worked  with  the  CBTDEV  to  refine  the  requirements  in  the  MCD.  The  program 
implemented  best  practices  like  competitive  prototyping  to  reduce  cycle  time  and  make 
sound  investments.  The  JPO  JLTV  increased  their  efficiency  by  adjusting  the  acquisition 
strategy  to  fill  the  capability  gaps  in  accordance  with  the  ICD  by  ensuring  that  all 
stakeholders  agreed  on  realistic  requirements. 

MCDs  requirements  must  be  managed  to  maximize  efficiency. 
The  JPO  JLTV  looked  at  the  requirements  management  best  practices  from  other 
programs.  The  program  implements  a  Requirements  Management  and  Analysis  Plan 
(RMAP)  for  the  technology  development  phase  of  the  acquisition  life  cycle.  The  RMAP 
addresses 

•  The  knowledge  gaps,  knowledge  point  timing,  events,  and 
execution; 

•  Roles,  responsibilities,  and  decision  authority; 

•  Change  management  of  key  documents,  including 
classified  annex; 

•  How  analyses  were  initiated,  tracked,  and  burned  down  and 
how  results  were  integrated  into  the  CDD/Specification; 
and 

•  Use  of  SE  software.  (Pflanz,  Yunker,  &  Wehrli,  2012,  p. 

11) 

Each  of  these  topics,  when  addressed  thoroughly,  has  provided  a 
tool  for  better  requirements  management,  as  outlined  in  the  JCIDS  documents.  The  JPO 
JLTV  learned  from  their  first  experience  moving  into  MS  B  and  wanted  to  ensure  that 
they  did  not  repeat  the  same  mistake  again.  The  JLTV  program  adopted  the  process  of 
RMAP  (Pflanz  et  al.,  2012)  to  assist  the  program’s  efforts  in  meeting  the  competitive 
prototyping  policy  established  by  the  USD(AT&L)  in  2007  to  ensure  they  were  meeting 
their  requirements  efficiently  (USD[AT&L],  2007).  As  stated  in  the  USD(AT&L) 
memo: 
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All  acquisition  strategies  requiring  USD(AT&L)  approval  must  be 
formulated  to  include  competitive,  technically  mature  prototyping  through 
MS  B.  The  component  Acquisition  Executives  will  review  all  existing 
programs  and  all  programs  in  the  initial  stages  of  development  for  the 
potential  to  adopt  this  acquisition  strategy.  (USD[AT&L],  2007,  p.  2) 

The  JLTV  went  through  the  technology  development  phase  for  30 
months  and  is  now  in  the  EMD  phase.  The  program  carried  three  different  companies  on 
separate  contracts  to  make  competitive  prototype  vehicles  and  eventually  will  select  a 
single  company  in  the  production  and  deployment  phase  (Pflanz  et  al.,  2012). 

/.  JLTV  Better  Buying  Power  2.0  Effectiveness  Analysis 

Eliminate  Redundancy  Within  Warfighter  Portfolios 

Rating:  Average 

JLTV’s  MCDs  outlined  capabilities  in  areas  within  the  Army’s  portfolio 
that  did  not  currently  exist. 

The  objective  of  the  JLTV  program  is  to  address  the  HMMWV  fleet’s 
protection,  payload,  and  performance  imbalance  within  a  transportable 
vehicle.  JLTV  is  expected  to  provide  comparable  protection  to  the  MRAP 
vehicles  in  most  cases — the  major  exception  being  underbody 
protection — but  with  better  payload  and  performance.  (GAO,  2010,  p.  4) 

As  the  new  platform  intended  to  replace  the  HMMWV,  the  JPO  JLTV  had 
to  understand  both  the  requirements  in  the  HMMWV ’s  portfolio  but  also  the  portfolios 
across  the  acquisition  community.  To  further  expound  on  this,  the  following  excerpt 
demonstrates  the  uniqueness  of  the  JLTV  and  that  it  is  not  a  redundant  system  and 
vehicle  to  the  HMMWV. 

The  HMMWV ’s  demonstrated  vulnerability  to  IEDs  and  the  difficulties 
and  costs  experienced  in  “up-armoring”  HMMWVs  already  in  the 
inventory  have  led  to  renewed  emphasis  on  vehicle  survivability.  DOD 
officials  have  emphasized  that  JLTVs  are  not  intended  to  replace 
HMMWVs  “one  for  one.”  (Feickert,  2013,  p.  1) 

The  described  fielding  plan  shows  that  redundancy  is  going  to  exist  within 
the  Army’s  vehicle  portfolio.  The  potential  is  created  for  some  Army  units  to  have  both 
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HMMWVs  and  JLTVs.  Units  possessing  both  vehicle  platforms  would  increase 
associated  time  and  costs  for  training  personnel  on  vehicle  operation  and  maintenance. 

There  are  capabilities  that  do  cross  over  and  match  up  with  other  existing 
vehicles.  One  such  capability  is  survivability  by  providing  a  high  level  of  protection  to 
the  vehicle.  This  is  seen  with  the  requirement  for  the  “JLTV  to  have  the  same  level  of 
under  body  protection  as  the  Mine-Resistant,  Ambush-Protected  All-Terrain  Vehicle  (M- 
ATV)”  (Feickert,  2013,  p.  3).  The  M-ATV  was  created  as  a  platform  that  provided 
integration  for  present  technology.  The  JLTV  is  focused  more  on  the  concepts  of  open- 
architecture  for  future  advancements  in  technology  and  engineering.  This  requirement 
was  outlined  in  the  JLTV’s  MCDs  to  ensure  that  the  JLTV  would  continue  to  effectively 
meet  its  mission  throughout  its  life  cycle. 

Another  similarity  is  found  with  the  transportation  of  personnel. 
Currently,  the  HMMWV  is  capable  of  transporting  two  to  five  personnel,  based  on  the 
variant.  The  JLTV  is  required  to  maintain  the  same  capability  as  the  HMMWV. 
Additionally,  the  M-ATV’s  capability  is  four  personnel.  Each  of  these  three  vehicles 
contains  the  same  capability  with  no  enhancement  to  carry  additional  personnel.  This 
personnel  requirement  displays  some  redundancy  within  the  Army’s  vehicle  portfolio. 
However,  this  redundancy  is  minimal  as  the  M-ATV  is  a  product  of  the  GWOT  and  a 
short-term  fill  during  development  of  the  vehicle  that  will  eventually  replace  the  majority 
of  HMMWV  variants. 

The  DoD  has  initiatives  in  place  to  prevent  the  duplication  of  acquisition 

efforts  with  programs  that  contain  similar  or  almost  exact  capabilities  that  mirror  each 

other.  Thus,  MCDs  must  also  adhere  to  this  consideration.  One  mechanism  to  control 

duplication  is  by  phasing  out  older  systems  and  slowly  halting  modernization  and 

replacement  programs.  The  JLTV  is  achieving  this  by  analyzing  the  evolutionary 

changes  to  the  HMMWV.  “DoD  intends  to  ‘protect’  the  JLTV  program  and  HMMWV 

modernization  would  be  terminated  so  that  resources  could  be  focused  on  the  JLTV” 

(Feickert,  2013,  p.  7).  Cancellation  of  the  HMMWV  modernization  program  ensures  that 

only  one  vehicle  program  is  moving  forward.  Efforts  are  not  duplicated  in  creating  and 

maintaining  vehicles  with  similar  capabilities,  therefore  reducing  redundancy  in  the 
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Army’s  portfolio  and  maximizing  effectiveness.  Additionally,  funds  become  available 
and  may  be  reallocated  from  one  program  to  another  as  efficient  reduction  in  the  portfolio 
occurs. 

Another  means  to  prevent  the  duplication  of  efforts  is  through  external 
auditors.  Consultants  can  analyze  the  new  program’s  MCDs  against  other  programs  that 
are  currently  in  existence.  This  is  accomplished  by  not  looking  at  just  other  platforms  but 
all  other  capabilities  that  may  be  inserted  on  the  JLTV.  Audit  findings  from  external 
organizations,  such  as  RAND,  allow  the  JPO  JLTV  to  clearly  identify  the  capability  gaps 
and  requirements  and  ensure  that  they  are  not  duplicating  efforts  of  other  programs. 
RAND’s  analysis  verified  the  accuracy  of  the  identified  capability  gaps  in  the  ICD  and 
requirements  in  the  CDD  (Kelly  et  al.,  2011). 

The  JLTV’s  MCDs  create  unique  capabilities  to  meet  the  future  force’s 
needs  through  an  array  of  fronts  worldwide.  Unlike  PM  M-ATV,  the  JPO  JLTV  also  has 
the  opportunity  to  ensure  increased  effectiveness  in  its  MCDs,  by  developing  the 
platform  to  project  a  future  sustainment  plan.  The  MCDs  have  served  to  effectively 
provide  a  means  to  prevent  redundancy  by  duplicating  existing  systems.  “A  comparison 
of  JLTV’s  capabilities  with  those  of  the  M-ATV  and  HMMWV  indicates  the  JLTV  is 
expected  to  offer  protection  levels  comparable  to  the  M-ATV  at  a  weight  nearer  to  the 
HMMWV”  (GAO,  2010,  p.  11).  This  has  allowed  the  program  to  not  duplicate  other 
capabilities  across  the  portfolios  and  has  potentially  preserved  present  and  future  funds. 

(1)  Improve  Requirements  Definition  and  Prevent 

Requirements  Creep. 

Rating:  Poor 

JPO  JLTV  has  faced  issues  due  to  requirements  creep. 

In  February  2011,  it  was  announced  the  award  of  the  EMD  contract  would 
be  delayed  until  January  or  February  2012  because  the  Army  changed 
requirements  for  the  JLTV.  DOD  had  planned  to  award  two  contracts  for 
the  EMD  phase,  which  was  scheduled  to  last  24  months,  but  instead 
proposed  a  48-month-long  EMD.  (Feickert,  2013,  p.  2) 
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Issues  such  as  this  decrease  the  effectiveness  of  a  program.  Delays 
resulting  from  increased  and  changing  requirements  have  forced  modifications  to  the 
CDD.  The  recently  approved  CDD  contains  changes  to  the  design  through  the  addition 
of  new  requirements.  In  addition,  untested  technologies  are  prevented  from  being  added 
to  a  system  or  require  extra  efforts  for  interoperability  with  existing  systems  not  required 
in  the  previous  CDD.  This  decreases  effectiveness  in  producing  a  system  based  on  the 
original  desired  capabilities. 

Another  issue  that  has  emerged  is  the  capability  to  match  the  same 
level  of  survivability  as  the  M-ATV.  Requirements  creep  affected  the  initial  MCDs. 
Repeating  the  technology  development  phase  has  increased  the  schedule  and  costs. 
However,  the  JPO  JLTV  has  overcome  this  obstacle  by  tailoring  their  acquisition  strategy 
to  meet  the  needs  of  the  new  capabilities  and  the  CBTDEV.  The  program  implemented 
the  initiative  for  competitive  prototyping  to  identify  the  best  capabilities,  not  just  the 
platform,  from  multiple  contractors.  This  creates  the  positive  effect  for  ensuring  that  the 
prototype  meets  all  the  MCDs’  requirements  and  mitigates  requirements  creep. 
Mitigation  occurs  from  a  contractor’s  having  to  demonstrate  their  design  and  by  having 
all  stakeholders  agree  on  the  preferred  design.  However,  there  also  is  an  ineffectiveness 
in  the  original  CDD.  The  program’s  second  time  through  the  TD  phase  shows  that  the 
MCDs’  requirements  were  not  effective  in  allowing  the  program  to  move  into  the  next 
phase  of  the  acquisition  life  cycle. 

The  JLTV  program  selected  three  contractors  to  produce  three 
prototypes  for  a  total  of  nine  vehicles  to  use  during  the  EMD  phase.  The  positive  effect 
from  this  course  of  action  is  the  preservation  of  funds  and  reduction  of  schedule  time 
(GAO,  2012).  This  increases  effectiveness  by  having  contractors  demonstrate  their 
vehicle  designs.  It  also  ensures  that  industry  has  mature  technologies  to  bring  to  the  table 
to  meet  the  requirements.  However,  the  downside  to  competitive  prototypes  is  that  the 
program  may  forgo  activities  that  occur  early  on  in  the  EMD  phase  to  ensure  the 
product’s  design  is  mature  and  meets  the  specified  requirements  (GAO,  2012).  Forgoing 
early  activities  can  create  potential  areas  of  risk  for  requirements  creep.  Potential  risk 
emerges  from  vehicles  that  do  not  possess  a  mature  design  in  the  later  phases  of  the 
program. 
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what  I  want  to  do  is  pay  for  it  [JLTV]  one  time  after  WIN-T  [Warfighter 
Information  Network-Tactical]  has  already  demonstrated  that  integration 
on  another  platform.  So  it  is  one  of  those  things  where  if  you  just  looked 
at  it  [additional  capabilities  insertion]  on  the  surface,  you  would  say  you 
have  added  risk  to  your  program  because  now  you  run  the  risk,  you  may 
not  be  able  to  host  WINT  in  a  fielded  JLTV.  If  you  took  no  actions  to 
prevent  that,  that  would  be  the  case  but  I  don’t  have  to  demonstrate  in 
EMD,  in  test,  to  be  able  to  reduce  that  risk  to  an  acceptable  level.  By  not 
doing  that,  I  was  able  to  save  enough  money  to  add  additional  RAM 
[reliability,  availability,  maintainability]  vehicles  and  to  buy  some 
additional  assets  that  we  needed  to  get  our  test  plan  approved.  So  it  was  a 
very  hard,  pragmatic  trade  that  was  made  at  the  very,  very  last  juncture. 

So  to  be  able  to  get  that  pulled  out  of  a  document  and  approved  by  the 
JROC  with  the  full  support  and  approval  of  the  user  community  was  I 
think  a  key  achievement.  That  required  a  lot  of  leaders  all  rolling  in  the 
same  direction.  (D.  Bassett,  personal  communication,  February  12,  2013) 

The  JPO  JLTV  was  able  to  benefit  from  the  competitive 
prototyping  to  enhance  the  requirements  within  the  MCDs.  Competitive  prototyping 
provides  the  program  office  the  ability  to  select  the  most  effective  design  that  adheres  to 
the  MCDs.  Additionally,  the  program  office  was  able  to  enhance  other  requirements 
after  seeing  the  demonstration  of  the  prototypes.  By  pursing  these  enhanced 
requirements,  the  program  office  is  able  to  potentially  decrease  future  requirements  creep 
within  the  area  of  RAM  and  prevent  modifications  to  the  MCDs’  requirements. 

The  JPO  JLTV  understood  the  importance  of  having  full  support 
and  collaboration  with  the  key  stakeholders  when  going  through  the  acquisition  life  cycle 
and  having  the  revised  CDD  approved  by  the  JROC.  Requirements  were  refined  through 
effective  communication  and  collaboration  between  all  parties  involved.  The 
requirements  of  the  CDD  had  buy  in  from  the  CBTDEV  and  the  program  office  to  ensure 
that  they  were  clearly  defined.  This  collaboration  assisted  the  JROC  in  its  final  approval 
on  March  15,  2012,  as  shown  in  Figure  38. 
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THE  JOINT  STAFF 

WASHINGTON,  D  C.  20310-8000 


JOINT  REQUIREMENTS 
OVERSIGHT  COUNCIL 


JROCM  036-12 
15  March  2012 


MEMORANDUM  FOR:  Distribution  List 

Subject:  Joint  Light  Tactical  Vehicle  Capability  Development  Document 

1  The  Joint  Requirements  Oversight  Council  (JROC)  reviewed  and  approves  the 
Joint  Light  Tactical  Vehicle  (JLTV)  Capability  Development  Document  (CDD)  and 
validates  the  enclosed  Key  Performance  Parameters  (KPPs).  The  JROC  considers  the 
KPPs  as  essential  to  meet  the  stated  mission  need.  The  JROC  designates  lead  for  this 
program  to  the  Army.  The  CDD  approval  authority  for  non-KPP  changes  is  delegated  to 
the  Army. 

2.  Should  the  Army  or  USMC  encounter  costs  exceeding  10  percent  of  the  approved 
acquisition  program  baseline  or  25  percent  of  the  original  program  baseline  (Program 
Acquisition  Unit  Cost  /  Average  Procurement  Unit  Cost),  the  Army  or  USMC  shall  return 
to  the  JROC  prior  to  reprogramming  or  budgeting  additional  funding  into  the  program. 


^AMES\A.  WINNEFgLtt,  JR. 
Admiral!  United  States  jNavy 
\.  Vice  Chairmah—^ 
ofthertjoint  Chiefs  of  Staff 


Figure  38.  JLTV  CDD  Approval  (From  JROC,  2012b,  p.l) 


Additionally,  the  JPO  JLTV  outlined  the  CBTDEV’s  requirements 
and  desired  capabilities  to  the  defense  industry.  This  may  prevent  the  government  from 
incurring  unnecessary  costs  for  unneeded  R&D  initiatives.  The  end  state  is  that  the 
government  can  pick  the  best  and  most  mature  technologies  that  minimize  future 
requirements  creep. 

g.  JLTV  Efficiency  and  Effectiveness  Analysis 
Figure  39  is  the  JLTV’s  MCDs  scorecard. 
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BBP  2.0  Principles  and  Initiatives  -  JLTV 


f  t  Rating 

|  Initiative  -  * 

Poor 

Average 

Excellent  1 

|  Efficiency  Initiatives  | 

(1)  Build  Stronger  Partnerships  With  The 

Requirements  Community  To  Control  Costs 

y 

(2)  Reduce  Cycle  Times  While  Ensuring  Sound 
Investment  Decisions 

y 

|  Effectiveness  Initiatives  | 

(1)  Eliminate  Redundancy  Within  Warfighter 
Portfolios 

y 

(2)  Improve  Requirements  Definition  And 

Prevent  Requirements  Creep 

y 

Figure  39.  JLTV  Overall  Rating  Scorecard 


Overall  Score 

Efficiency:  1  x  Average,  1  x  Excellent 
Effectiveness:  1  x  Poor,  1  x  Average 


Figure  40  depicts  our  overall  rating  of  the  JLTV’s  MCDs. 


140 


Figure  40.  JLTV  Efficiency  and  Effectiveness  Analysis  (After  Griiter  &  Boerendans,  2013) 
Overall  Rating 

Efficiency:  Average-Excellent 
Effectiveness:  Poor-Average 

The  JLTV  receives  an  efficiency  rating  of  average-excellent.  Efficiency 
of  the  MCDs  results  in  using  the  minimum  resources  to  provide  the  right  materiel 
solution.  Stakeholders  must  be  synchronized  with  each  other’s  missions.  The  JLTV 
MCDs  were  created  through  the  efficiencies  of  two  cultures  and  their  ability  to 
collaborate  between  multiple  organizations  to  establish  trade-offs.  This  allowed  the 
program  to  get  back  on  track.  Collaboration  and  agreements  improved  the  ability  to 
conduct  trade-offs  on  requirements.  However,  the  program  was  unable  to  preserve  the 
cycle  time  when  trying  to  adjust  requirements.  This  in  return  would  preserve  funds  but 
increase  time  needed  for  the  program.  Policy  changes,  in  conjunction  with  the  MCDs, 
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yielded  additional  efficiencies.  The  new  competitive  prototyping  and  use  of  the  draft 
RFP  assist  the  MCDs  in  producing  efficiencies  in  the  program  by  reducing  costs  by 
enforcing  validated  designs  prior  to  entering  into  the  production  and  deployment  phases. 

The  JLTV  receives  a  rating  of  poor-average  for  effectiveness.  Effective 
MCDs  allow  a  materiel  solution  to  traverse  through  the  acquisition  process  with  the 
feasibility  of  developing,  writing,  and  understanding  everything  that  is  composed  within 
the  documents.  The  JLTV  had  clearly  defined  requirements  outlined  by  the  MCDs  found 
in  the  second  CDD.  Effectiveness  has  yet  to  be  achieved  by  reducing  redundancies  in  the 
portfolios.  Since  JLTV  has  not  entered  production  and  deployment,  a  one  for  one  swap 
for  the  HMMWV  is  currently  not  going  to  take  place  and  M-ATV  remains  in  the 
warfighting  portfolio.  Additionally,  an  effective  document  comes  from  the  ability  to 
address  capabilities  and  the  clarity  of  the  written  requirements.  These  attributes  assist  the 
program  office  in  performing  proper  life-cycle  management  and  managing  cost,  schedule, 
and  performance.  The  JLTV  program  demonstrates  how  effective  collaboration  among 
the  different  stakeholders  increases  the  experience  of  the  workforce  directly  involved  in 
the  writing  and  execution  of  MCDs  for  greater  effectiveness. 

C.  CHAPTER  SUMMARY 

Our  research  has  revealed  that  through  MRDs/MCDs,  program  offices  are  able  to 
produce  materiel  solutions  at  an  increased  level  of  efficiency;  however,  the  program  may 
still  experience  a  decreased  level  of  effectiveness.  Lurthermore,  the  MRDs  were  less 
efficient  and  effective  than  the  MCDs.  Nonetheless,  the  MCDs  so  far  have  been  equally 
effective,  but  there  has  been  an  increase  in  efficiency  from  M-ATV  to  JLTV. 

Our  research  is  focused  on  the  MRDs/MCDs  that  produced  materiel  solutions  for 
three  wheeled  platforms,  and  not  the  platform’s  efficiency  and  effectiveness  on  the 
battlefield.  We  combined  our  analysis  by  integrating  the  concepts  of  efficiency  and 
effectiveness,  together  with  the  proper  type  of  change  and  change  management  that  has 
occurred  throughout  the  history  of  the  RGP,  and  four  initiatives  of  BBP  2.0.  We  scored 
three  program  offices’  MRDs/MCDs  against  these  concepts.  The  overall  scores  for  all 
three  wheeled  platforms  are  displayed  in  Ligure  41. 
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BBP  2.0  Principles  and  Initiatives  Consolidated  Case  Study  Analysis 


Rating 

Initiative 

HMMWV  MRDs 

M-ATVMCDs 

JLTV  MCDs 

|  Efficiency  Initiatives 

(1)  Build  Stronger  Partnerships  With  The 

Requirements  Community  To  Control  Costs 

POOR 

AVERAGE 

EXCELLENT 

(2)  Reduce  Cycle  Times  While  Ensuring  Sound 
Investment  Decisions 

AVERAGE 

AVERAGE 

AVERAGE 

|  Effectiveness  Initiatives  |j 

(1)  Eliminate  Redundancy  Within  Warfighter 

Portfolios 

POOR 

AVERAGE 

AVERAGE 

(2)  Improve  Requirements  Definition  And 

Prevent  Requirements  Creep 

POOR 

POOR 

POOR 

Overall  Score  Efficiency 

POOR- 

AVERAGE 

AVERAGE 

AVERAGE  - 

EXCELLENT 

Overall  Score  Effectiveness 

POOR 

POOR- 

AVERAGE 

POOR- 

AVERAGE 

Figure  41.  BBP  2.0  Initiative  Scorecard  Roll-Up 


We  have  assessed  the  MRDs/MCDs  for  these  platforms  and  consolidated  them 
onto  one  model  to  reveal  our  results.  This  links  our  scoring  of  efficiency  and 
effectiveness  scores,  the  BBP  2.0  initiatives,  and  evolutionary  and  revolutionary  change 
appear  in  Figure  42. 
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Figure  42.  Platforms  Efficiency  and  Effectiveness  Analysis 
(After  Griiter  &  Boerendans,  2013) 

“Efficiency”  was  measured  on  how  well  the  MRDs/MCDs  “Did  Things  Right”  in 
regards  to  the  BBP  2.0’s  two  initiatives,  (1)  Build  Stronger  Partnerships  With  The 
Requirements  Community  to  Control  Costs  and  (2)  Reduce  Cycle  Times  While  Ensuring 
Sound  Investment  Decisions.  On  the  other  hand,  “Effectiveness”  was  measured  on  how 
well  the  MRDs/MCDs  “Did  the  Right  Things”  in  regards  to  BBP  2.0’s  two  initiatives,  (1) 
Eliminate  Redundancy  within  Warfighter  Portfolios  and  (2)  Improve  Requirements 
Definition;  Prevent  Requirements  Creep. 

Overall,  the  MRDs/MCDs  should  be  “Doing  the  Right  Things  Right”  if  they  are 
to  maximize  efficiency  and  maximize  effectiveness.  We  have  assessed  HMMWV,  M- 
ATV,  and  JLTV’s  requirements  and  capability  documents  to  compare  their  scores  against 
each  other.  Our  comparative  analysis  is  revealed  in  Figure  42. 
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First,  the  HMMWV  MRDs  efficiency  and  effectiveness  overall  rating  is  in  the 
“Doing  Things”  quadrant.  For  HMMWV  documents  to  increase  in  efficiency  or 
effectiveness,  the  documents  demand  the  need  for  evolutionary  changes  or  perhaps  a 
revolutionary  change  in  order  to  increase  their  scores  in  regards  to  the  BBP  2.0 
initiatives.  Data  gathered  showed  that  HMMWV  program  did  not  go  through  a 
revolutionary  change  of  RGS  to  JCIDS  and  continued  to  use  MRDs  instead  of  MCDs. 
Ultimately,  the  JCIDS  was  implemented  and  MRDs  ceased  to  evolve  and  were 
revolutionized  by  the  MCDs. 

Second,  the  M-ATV  MCDs  efficiency  and  effectiveness  overall  rating  is  on  the 
cusp  of  “Doing  Things”  and  “Doing  Things  Right.”  This  reveals  M-ATV  MCDs  have 
increased  in  efficiency  and  effectiveness.  Evolutionary  and  revolutionary  changes  to  the 
documents  are  not  greatly  demanded;  however,  there  are  still  areas  for  refinement. 

Finally,  the  JLTV  MCDs’  efficiency  and  effectiveness  overall  rating  has  placed 
the  icon  in  “Doing  Things  Right”  quadrant.  The  JLTV  MCDs  received  the  highest  score 
on  the  efficiency  axis  and  an  equal  rating  with  M-ATV  on  the  effectiveness  axes.  This 
reveals  that  the  JCIDS  MCDs  have  increased  in  efficiency.  Of  note,  JLTV  has  yet  to 
enter  the  production  and  deployment  phase  of  the  life  cycle.  However,  based  on  our  BBP 
2.0  measurements,  the  JLTV  program’s  MCDs  have  scored  higher  than  the  other  two 
platforms  of  HMMWV  MRDs  and  M-ATV  MCDs.  Our  qualitative  information  shows 
that  increase  in  efficiency  and  effectiveness  is  strongly  based  on  the  key  stakeholders’ 
recognition  of  the  mistakes  of  the  past  and  implementation  of  best  practices. 

In  closing,  HMMWV’s  MRDs  have  undergone  a  revolutionary  change  due  to  the 
lack  of  efficiency  and  effectiveness.  The  JCIDS  MCDs  have  made  great  strides  in 
improving  the  efficiency  and  effectiveness  (depicted  by  the  M-ATV  MCD  icon)  and  are 
continually  reaching  greater  effectiveness  (depicted  by  the  JLTV  MCD  icon).  Therefore, 
the  JCIDS  MCDs  are  evolving  in  the  right  direction  to  support  the  programs  executing 
the  DAS. 

Both  efficiency  and  effectiveness  begin  with  the  manner  in  which  requirements 
and  capability  gaps  are  created  and  defined.  However,  to  truly  be  efficient  and  effective, 
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these  requirements  must  not  simply  meet  a  current  capability  gap  but  also  anticipate 
future  capability  gaps.  There  are  many  external  factors  outside  the  MRDs/MCDs  that 
contribute  to  requirements  creep,  such  as  emerging  threats  and  advancement  in 
technology.  That  does  not  mean  that  key  stakeholders  should  not  anticipate  possible 
foreseeable  factors  that  change  the  requirements.  All  key  stakeholders  must  have  the 
ability  to  project  uncertainty  and  the  flexibility  to  quickly  adapt.  If  all  stakeholders  work 
collaboratively,  the  current  MCDs  will  be  able  to  continuously  provide  the  best  materiel 
solution  for  the  warfighter. 
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V.  SUMMARY,  CONCLUSION,  RECOMMENDATIONS,  AND 
AREAS  FOR  FURTHER  RESEARCH 


A.  SUMMARY 

At  first,  we  believed  that  revolutionary  change  would  be  required  in  order 
for  materiel  MRDs/MCDs  to  be  efficient  and  effective  based  on  comparison  of 
documents  from  two  different  RGPs  (the  RGS  and  JCIDS).  In  the  end,  we  came  to  a 
very  different  realization  as  we  conducted  our  research  and  analysis.  The  following 
summary  recaps  our  previous  chapters: 

•  In  Chapter  I,  we  introduced  our  paper  by  outlining  our  research  questions 
and  scope. 

•  In  Chapter  II,  we  provided  the  necessary  background  information  upon 
which  we  based  our  research  and  analysis. 

•  In  Chapter  III,  we  presented  the  methodology  for  our  project. 

•  In  Chapter  IV,  we  detailed  our  qualitative  focus  and  presented  our 
comparative  analysis  through  the  use  of  case  studies. 

Now,  at  the  final  portion  of  our  project  (Chapter  V),  we  deliver  our  conclusion, 

recommendations,  and  areas  for  further  research. 

B.  CONCLUSIONS 

1.  Research  Findings 

Our  study  examined  the  following  questions: 

•  What  makes  requirement  documents  efficient  and  effective,  or  inefficient 
and  ineffective  for  the  stakeholders  who  facilitate  the  RGP? 

•  What  key  differences  exist  in  the  documents  from  the  old  RGS  process 
compared  to  the  new  JCIDS  process,  and  why  were  these  changes  made 
during  this  transition? 

•  Does  future  change  need  to  be  evolutionary  or  revolutionary? 
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a.  What  makes  requirement  documents  efficient  and  effective,  or 
inefficient  and  ineffective  for  the  stakeholders  who  facilitate  the 
RGP? 

In  our  study,  we  concluded  that  efficiency  for  MRDs/MCDs  is  a  laborious 
balancing  act  of  many  factors  and  considerations  that  involves  the  stakeholder  and 
acquisition  processes.  Too  much  or  too  little  consideration  will  unbalance  the  scale  and 
shift  the  focus  to  specific  stakeholders.  This  may  cause  a  chain  reaction  that  will 
ultimately  hinder  a  materiel  solution.  For  instance,  if  the  CBTDEV  is  solely  concerned 
with  writing  requirements  for  the  warfighter  without  consideration  of  critical  acquisition 
processes,  the  result  may  be  a  solution  that  does  not  really  meet  the  identified  capability 
gap.  Remember,  “if  you  want  it  bad,  you’ll  usually  get  it  bad”  (P.  Mann,  personal 
communication,  November  19,  2012). 

An  efficient  materiel  requirements  document  is  one  written  to  cater  to  the 
preponderance  of  stakeholders  who  must  staff,  approve,  and  execute  the  primary 
functions  of  that  requirement  document.  MRDs/MCDs  are  not  egocentric.  The 
CBTDEV  cannot  write  requirements  without  consideration  of  the  acquisition  process. 
The  program  offices  should  not  demand  requirements  that  identify  an  exact  product  but 
performance  based.  However,  they  must  place  full  consideration  into  the  missions  of  the 
CBTDEV  and  other  key  stakeholders’  organizations.  The  JROC  should  not  ask  for 
MRDs/MCDs  to  be  written  just  to  ease  staffing  and  processing.  Requirements  must 
promote  efficiency  for  all  stakeholders.  The  authors  of  the  MRDs/MCDs  must 
understand  the  constraints  and  limitations  of  the  format.  The  CBTDEV,  acquisition 
workforce,  JROC,  and  other  key  stakeholders  require  alignment  of  tasks  and  processes  to 
produce  the  right  solution.  This  alignment  comes  from  understanding  of  the  processes, 
capabilities  and  constraints,  and  environment  internal  and  external  to  the  stakeholders’ 
organizations. 

Efficiency  is  purely  creating  a  proficient,  capable  network.  All 
stakeholders  of  the  RGP  achieve  efficiency  through  alignment  and  understanding  of  their 
partners’  cultures.  This  may  occur  through  personnel  exchange  programs  such  as 
CBTDEV  and  program  office  personnel  rotating  through  a  Department  of  the  Army 
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Systems  Coordinator  (DASC)  developmental  duty  assignment.  Service  in  this  position 
allows  key  people  to  understand  the  inner  workings  of  the  Pentagon  and  the  acquisition 
process.  Furthermore,  including  the  CBTDEV  in  the  acquisition  process,  inviting  them 
to  program  reviews,  helps  ensure  a  clear  understanding  of  requirements  by  every 
stakeholder. 

The  intent  for  MRDs’  format  to  transition  into  MCDs’  format  were  to 
better  streamline  the  process.  However,  while  there  is  always  room  for  improvement,  if 
those  who  prescribe  the  format  continually  change  the  process,  it  forces  all  stakeholders 
to  continually  adapt.  This  constant  adaptation  will  limit  learning  and  make  it  difficult  for 
any  stakeholder  to  be  a  subject-matter  expert  in  writing  MRDs/MCDs.  This  detracts 
from  efficiency. 

The  stakeholders  must  recognize  where  in  the  life-cycle  system 
management  process  the  requirements  (capability)  document  fits  and  the  gates  that  the 
documents  must  pass  through  to  be  approved  prior  to  the  next  phase  and  milestone. 
Efficient  requirement  documents  must  be  written  well  enough  to  enable  a  materiel 
solution  to  move  along  through  the  phases  of  the  acquisition  life  cycle.  Additionally,  the 
documents  must  be  effective  in  minimizing  future  changes  to  that  materiel  solution, 
which  would  require  ECPs.  This  is  how  efficient  MRDs/MCDs  enable  an  effective 
materiel  solution  for  the  warfighters. 

b.  What  key  differences  exist  in  the  documents  from  the  old  RGS 
process  compared  to  the  new  JCIDS  process,  and  why  were  these 
changes  made  during  this  transition? 

In  response  to  Question  2,  we  identified  key  differences  in  the 
MRDs/MCDs  that  supported  both  the  RGS  and  the  JCIDS.  The  detailed  formats  for  each 
document  can  be  revisited  in  Chapter  II. 

Formats  for  the  documents  for  the  RGS  and  JCIDS  were  very  different. 
The  documents  varied  in  required  length  and  format.  The  MNS  had  a  limitation  of  just 
five  pages,  while  the  ICD  limitation  doubled  to  10  pages.  The  MNS  contained  six  parts 
in  its  format,  while  the  ICD  contains  three  primary  parts  (Part  2  contained  eight  subparts 
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and  Part  3  contained  seven  sections)  and  requires  four  appendices.  The  change  in  format 
structure  allows  information  to  be  captured  with  greater  fidelity.  Beyond  differences  in 
the  format  structure,  there  are  also  differences  concerning  the  purpose  and  intent  of 
sections  between  the  RGS  and  JCIDS  documents.  A  major  change  from  the  MNS  to  ICD 
was  that  the  ICD  identifies  a  capability  gap  while  the  MNS  outlined  a  requirement  need. 
Another  difference  comes  from  the  MNS  using  DTLOMS  for  analysis,  but  the  ICD  used 
DOTMLPF  and  now  uses  DOTmLPF-P  for  analysis.  Changes  in  the  analysis  ideology 
provide  a  more  expansive  concept  to  a  broader  group  of  stakeholders. 

The  ORDs  formats  for  both  the  initial  and  revised  versions  are  the  same. 
The  only  difference  came  with  the  capacity  for  revision  for  production  modification  in 
the  RGS,  if  change  was  necessary.  An  ORD-Initial  written  to  support  production  activity 
would  remain  the  same,  but  could  change  as  required  after  JROC  approval. 

The  JCIDS  separated  the  ORD  into  two  distinct  documents,  the  CDD  and 
CPD.  The  main  reason  for  the  creation  of  two  documents  from  one  document  came  from 
the  lack  of  restrictions  for  the  ORD.  The  ORD  does  not  have  a  page  restriction  and  can 
go  through  multiple  paths  for  approval,  as  long  as  approval  occurs  at  the  appropriate 
level.  Additionally,  the  ORD’s  format  had  eight  parts  with  Part  4  containing  four 
subparts  and  Part  5  containing  nine  subparts.  This  structure  caused  the  document  to  be 
very  vague  and  allowed  for  a  great  deal  of  interpretation  by  the  authors  in  identifying  the 
requirements.  This  created  discrepancies  and  ambiguities  in  the  RGS’s  requirements 
documents  (MNS  and  the  two  ORDs),  which  ultimately  created  difficulty  for  the 
stakeholders  to  execute  various  acquisition  processes. 

Unlike  the  RGS  requirements  documents,  the  JCIDS  capabilities 

documents  contained  greater  structure  and  restrictions  to  control  the  information  that  is 

placed  in  the  document.  The  CDD  has  five  parts  with  Part  3  containing  16  subsections 

and  is  specifically  constrained  to  not  exceed  45  pages.  The  body  of  a  CPD  consists  of 

five  primary  parts,  the  16  primary  subsections,  and  Appendix  A,  all  of  which  cannot 

exceed  40  pages.  Additionally,  the  ICD,  CDD,  and  CPD  formats  have  clearly  defined 

instructions  for  their  completion.  The  majority  of  the  parts  and  sections  in  the  JCIDS 

documents  clearly  outline  the  expectations  of  how  sentences  begin  and  what  is  in  every 
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part  of  the  documents.  The  JCIDS  documents  provide  better  standardization  for  all 
stakeholders.  If  stakeholders  need  to  reference  only  a  part  of  the  document,  for  example 
Spectrum  Requirements,  they  know  the  exact  section  that  is  to  contain  all  the  details 
(Part.4.h).  While  portions  of  the  RGS  documents  could  accomplish  the  same  level  of 
detail,  the  JCIDS  documents  have  clearly  anticipated  more  technology  considerations  for 
integration. 

Adjustment  to  the  new  way  of  thinking,  in  regards  to  a  capability  gap 
instead  of  a  requirement  need,  has  been  beneficial  to  all  stakeholders.  Requirements 
often  employ  very  technical  information.  An  example  of  this  is  the  following:  the 
warfighter  asks  for  an  M4  rifle  requirement,  instead  of  asking  for  the  capability  of  a 
weapon  that  does  not  weigh  more  than  12  lbs,  has  an  effective  range  of  500  meters,  and  is 
integrated  with  optics.  Proceeding  based  on  the  direction  of  the  capability  versus  the 
need  allows  the  executors  of  the  MRDs/MCDs  to  seek  out  and  provide  the  most  effective 
capability. 

Along  with  achieving  a  more  effective  solution,  using  capabilities 
provides  horizontal  networks  to  connect  the  different  stakeholders’  communities. 
Actions  involved  with  each  of  the  different  capability  documents  (ICD,  CDD,  CPD) 
occur  sequentially  and  are  more  streamlined  (efficient)  as  all  stakeholders  are  constantly 
working  in  a  synchronized  method.  The  CBTDEV  can  outline  the  capability,  and  the 
acquisition  community  is  able  to  comment  back  to  the  CBTDEV  on  which  capabilities 
are  technically  mature  and  cost  effective. 

c.  Does  future  change  need  to  be  evolutionary  or  revolutionary? 

Finally  for  Question  3,  we  have  identified  that  evolutionary  change  may 
continue  to  develop  the  JCIDS  capabilities  documents  to  achieve  higher  levels  of 
efficiency  and  effectiveness.  Yet,  a  revolutionary  change  would  be  more  detrimental 
than  beneficial.  Additionally,  to  implement  change  in  large  organizations,  such  as  the 
defense  industry  that  supports  Army  acquisitions,  is  slow  and  arduous. 

History  reveals  that  the  DoD  and  the  industrial  base  has  been  challenged 
to  meet  the  requirements  of  the  warfighter  during  the  midst  of  the  turmoil  of  war.  For 

151 


instance,  during  World  War  II  the  U.S.  military  had  to  adapt  to  counter  the  threat  of  the 
German  U-boats  by  developing  new  capabilities  such  as  the  B-24  Liberator  bomber  to 
assist  in  defeating  the  threat.  Later  during  the  Vietnam  War  the  M-72,  66-mm  Light 
Anti-Tank  Weapons  (LAWs)  served  as  bunker  busters  to  defeat  the  threat  of  hidden 
bunkers  in  the  jungle.  The  LAW  was  an  existing  system.  Finally,  the  MRAP  FoV  came 
about  to  counter  IED  threats  during  the  GWOT.  Each  materiel  solution  came  by  means 
of  its  own  respective  RGPs  and  associated  documents. 

The  JCIDS  capabilities  documents  have  undergone  evolutionary  changes 
during  the  last  decade  of  war.  The  current  capabilities  documents  of  the  ICD,  CDD,  and 
CPD  must  have  an  opportunity  to  prove  their  relevancy  during  more  stable  times. 
Furthermore,  few  large  acquisition  programs  have  yet  to  proceed  through  the  entire 
JCIDS  process.  Revolutionary  change  would  only  create  more  havoc  than  order. 
Stakeholders  are  only  now  starting  to  understand  the  full  JCIDS  process  and  the 
associated  documents.  Creating  a  new  process  and  or  documents  would  serve  to 
eliminate  all  of  the  knowledge  and  experience  that  recent  generations  of  the  defense 
workforce  and  defense  industry  have  developed  over  the  last  10  years  with  the  JCIDS 
process. 

2.  Recommendations 

a.  Continue  to  refine  the  capabilities  documents  in  support  of 
modifications  to  the  JCIDS  process,  as  needed 

Our  first  recommendation  is  to  continue  to  refine  the  capabilities 
documents  in  support  of  modifications  to  the  JCIDS  process,  as  needed.  In  2003,  a 
revolutionary  change  was  necessary  to  cease  the  RGS  and  developed  the  JCIDS  in  order 
to  refine  the  requirements  generation  process  and  its  supporting  documents.  The  JCIDS 
and  its  supporting  capabilities  documents  have  served  their  purpose  throughout  the 
GWOT.  However,  the  JCIDS  and  its  capabilities  documents  have  not  had  the 
opportunity  to  fully  prove  their  effectiveness  in  defense  acquisition  during  peace  time. 
The  requirements,  acquisition,  and  defense  industry  workforce  are  still  implementing  best 
practices  and  changing  each  of  their  cultures  to  align  with  the  JCIDS  process. 
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Furthermore,  the  acquisition  and  DoD  workforce  has  implemented  and  learned  to  utilize 
the  JCIDS’  capabilities  documents  for  over  a  decade. 

There  are  many  benefits  that  may  be  gained  by  continuing  to  utilize  the 
current  JCIDS’  capabilities  documents.  Revolutionary  change  tends  to  result  in  great 
disruptions  in  established  cultures.  The  JCIDS  and  its  supporting  capabilities  documents 
are  still  in  their  early  stages  of  maturity.  Continually  evolving  the  JCIDS  capabilities 
documents  will  minimize  the  learning  curve  for  its  SMEs. 

b.  Improve  the  quality  of  requirements  writing 

A  second  recommendation  is  to  improve  the  quality  of  requirements 
writing.  It  is  critical  to  continually  improve  the  efficiency  of  JCIDS  capabilities 
documents  in  order  to  better  guide  the  process  of  creating  a  materiel  solution.  BBP  2.0 
outlines  the  importance  of  clearly  defined  requirements  for  all  stakeholders.  The  DoD 
must  continue  to  impress  the  importance  of  requirements  writing  as  a  primary  profession 
and  not  just  simply  an  additional  duty.  Additionally,  Congress  has  recognized  the 
importance  of  writing  quality  requirements.  Poorly  written  capabilities  documents  often 
lead  to  requirements  creep.  Better  quality  and  more  understandable  capabilities 
documents  can  anticipate  and  prevent  requirements  creep.  Anticipation  may  prevent 
future  ECPs.  This  could  result  in  cost  avoidance.  Also,  no  ECP  means  there  is  no  need 
to  change  the  system  design  or  conduct  re-engineering  to  achieve  an  added 
performance/capability.  This  helps  preserve  the  acquisition  schedule. 

Employing  best  practices  will  shape  better  definition  of  requirements  that 
are  capability  based  and  will  meet  the  initiatives  of  BBP  2.0.  The  defense  industry  will 
continue  to  challenge  itself  with  new  and  future  technologies.  The  DoD  can  leverage  this 
effort  in  cost  savings  in  R&D  while  still  obtaining  the  most  cutting-edge  technologies. 
However,  the  DoD  must  be  at  the  forefront  of  requirements  definition.  Capability  gaps 
drive  the  requirements  that  drive  a  materiel  solution.  That  being  said,  using  our  previous 
example  of  efficiency  and  effectiveness  with  the  mortar  team,  the  DoD  must  seek  out  the 
capability  to  effectively  destroy  a  bunker  versus  demanding  a  requirement  of  a  120-mm 
mortar  shot  from  a  tube  that  meets  the  expectations.  If  a  bunker  can  be  taken  out  with 
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another  materiel  solution  that  possesses  greater  effectiveness  than  a  120-mm  mortar,  and 
is  more  efficient  and  effective  within  the  parameters  of  the  acquisition  process,  then  this 
is  the  right  solution  to  fill  the  capability  gap.  The  defense  industry’s  capabilities  and  its 
technological  advancements  can  meet  capability  gaps.  However,  the  DoD  cannot  be 
overly  confident  in  these  technologies,  which  may  result  in  a  “conspiracy  of  hope.”  This 
conspiracy  of  hope  leads  to  failed  programs  like  the  Army’s  Future  Combat  Systems 
(FCS)  that  was  neither  efficient  nor  effective. 

The  John  Warner  National  Defense  Authorization  Act  for  Fiscal  Year 
2007,  Section  801  (109  U.S.C.,  2007,  §  801  [a-c]),  introduced  the  initiative  for  a 
Requirements  Management  Certification  Training  (RMCT)  Program.  This  policy 
mandates  that  those  with  authority  within  the  DoD  who  generate  requirements  cannot 
participate  in  authoring  requirements  without  receiving  certification.  The  DAU  has 
created  courses  and  has  outlined  the  curriculum  for  the  certification.  Currently,  there  are 
five  required  courses,  based  on  duty  position  and  grade.  These  courses  are  CLR  101: 
Introduction  to  JCIDS,  RQM  110:  Core  Concepts  for  Requirements  Management,  RQM 
310:  Advanced  Concepts  and  Skills  for  Requirements  Managers,  RQM  403: 
Requirements  Executive  Overview  Workshop,  and  RQM  413:  Senior  Leader 
Requirements  Course.  The  effectiveness  of  these  prescribed  courses  has  yet  to  be 
proven,  but  requiring  them  is  a  move  in  the  right  direction.  These  requirements  courses 
and  certification  are  not  limited  to  individuals  responsible  for  writing  requirements. 
Anyone  in  the  DoD  workforce  may  attend  the  courses.  Members  of  the  DoD  workforce 
that  are  stakeholders  dealing  with  capabilities  documents  would  benefit  from  taking  these 
courses  as  well.  Leadership  must  also  reinforce  this  training  in  order  to  create  an 
efficient  requirements  workforce  within  their  organizations.  The  DoD  community  can 
only  benefit  by  ascribing  to  better  requirements  definition  through  training  and  better 
understanding  of  the  JCIDS  process. 

c.  Requirements  focus  on  a  perceived  capability  and  not  the 
identification  of  a  specific  materiel  solution 

The  third  recommendation  is  to  ensure  requirements  focus  on  a  perceived 

capability  and  not  the  identification  of  a  specific  materiel  solution.  This  may  be  more 
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challenging  than  it  sounds.  The  defense  industry  continues  to  be  at  the  forefront  of 
technology  and  the  DoD  continues  to  stress  the  importance  of  purchasing  commercial- 
off-the-shelf  items.  Furthermore,  the  defense  budget  continues  to  become  more 
constrained.  The  defense  industry  struggles  to  survive  during  periods  of  constrained 
DoD  budgets.  In  their  struggle  to  survive,  the  defense  industry  attempts  to  showcase  its 
new  technologies  to  those  stakeholders  who  develop  requirements.  Warfighter 
requirements  may  not  identify  a  direct  materiel  solution,  but  the  capability  documents 
have  the  potential  to  be  written  in  such  a  way  that  there  is  only  one  materiel  solution. 
The  DoD  workforce  must  be  vigilant  in  its  efforts  to  ensure  that  this  does  not  occur  or 
become  common  practice.  Capability  gaps  must  be  identified  in  a  way  that  allows  the 
acquisition  workforce  to  work  within  identified  constraints  to  fill  these  gaps.  Capability- 
based  principles  can  only  benefit  the  DoD. 

Embrace  the  best  practice  of  “trade-offs”  as  a  tool  when  refining  the 
requirements  of  a  material  solution 

Our  fourth  recommendation  is  to  fully  embrace  the  best  practice  of  “trade¬ 
offs”  as  a  tool  when  refining  the  requirements  of  a  material  solution.  The  capability  gaps 
are  identified  in  the  ICD  by  the  CBTDEV.  After  the  MDA  has  identified  that  the 
materiel  solution  is  needed,  stakeholders  must  cooperatively  work  together  to  produce  the 
best  product  for  the  warfighter.  The  CBTDEV’s  intent  is  to  be  a  steward  of  the 
warfighters  and  provide  them  with  everything  that  they  require,  but  often  providing 
everything  is  not  realistic  due  to  the  many  constraints  in  the  defense  acquisition  process. 
There  are  many  trade-offs  that  may  be  made  in  order  to  come  to  a  desired  end  result. 
Trade-offs  exist  in  multiple  capabilities,  between  the  adjustment  of  threshold  and 
objective  goals,  the  reclassification  of  a  KPP  to  a  regular  requirement,  and  even  within 
DOTmLPF-P  analysis,  to  name  a  few. 

The  balance  between  survivability  and  maneuverability  is  an  example  of  a 

requirements  trade-off.  Survivability  usually  requires  additional  weight  and  takes  away 

from  maneuverability.  Thus  neither  threshold  nor  objective  values  would  be  met  for 

either  requirement.  The  CBTDEV’s  willingness  to  make  trade-offs  is  the  solution.  The 

priority  that  identifies  survivability  over  maneuverability  is  half  the  solution.  The  other 
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half  comes  into  play  with  a  trade-off  between  objective  and  threshold  values.  A  trade-off 
can  be  established  to  decrease  the  expected  threshold  value  of  maneuverability  in  order  to 
reach  the  threshold  value  of  survivability  for  the  solution.  This  collaboration  on  trade¬ 
offs  between  stakeholders  is  essential  in  defining  requirements.  Stakeholders  must 
always  remember  that  every  organization  has  the  best  interests  of  the  warfighter  in  mind. 
Working  on  realistic  and  reasonable  trade-offs  allows  everyone  to  build  stronger 
relationships  and  enhance  the  government  requirement  network. 

d.  RGP  community  does  not  repeat  the  mistakes  of  the  past 

Our  fifth  and  final  recommendation  is  that  the  RGP  community  does  not 
repeat  the  mistakes  of  the  past.  We  are  at  a  volatile  time  in  the  DoD  since  we  have  been 
a  nation  at  war  for  over  a  decade.  The  RGP  community  has  done  great  things  to  support 
the  warfighter.  However,  this  same  community  must  have  the  humility  to  identify  the 
critical  shortfalls  and  mistakes  that  have  also  been  made.  Many  of  these  shortfall  and 
mistakes  have  already  been  recognized  in  numerous  reports  and  studies  by  organizations 
like  the  GAO,  CRS,  and  Defense  Business  Board.  Nevertheless,  it  is  important  that 
requirements  stakeholders  not  stand  by  for  these  external  think-tanks  to  identify 
solutions.  Requirements  stakeholders  must  develop  and  integrate  their  own  after  actions 
review  and  lessons  learned  to  develop  and  implement  best  practices  for  the  requirements 
generation  workforce. 

Furthermore,  the  solutions  that  come  from  self-analysis  cannot  fall  on  deaf 
ears  or  become  a  document  that  no  one  ever  reads.  The  requirements  community  must 
take  time  as  the  wars  wind  down  to  pause  and  scrutinize  how  the  capabilities  documents 
have  evolved  during  the  JCIDS  process.  Then  they  must  implement  the  best  practices 
until  they  become  standard  practice,  and  create  additional  standards  to  ensure  that  the 
failures  of  the  past  are  never  repeated  in  their  organizations.  This  will  result  in  positive 
evolutionary  change  within  the  requirements  generation  workforce.  AARs  are  only  good 
if  they  are  used. 
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C.  AREAS  FOR  FURTHER  RESEARCH 

This  section  contains  two  subsections.  The  first  subsection  identifies  ways  to 
expand  our  study.  The  second  subsection  outlines  four  related  projects  that  may  be 
conducted  as  future  research  to  further  advance  knowledge  beyond  the  point  of  this 
project. 


1.  Expanded  Study  to  Other  Program  Offices 

We  used  a  qualitative  methodology  when  conducting  our  research.  We  conducted 
due  diligence  to  eliminate  personal  bias  when  doing  the  study  and  ensured  that  we 
remained  objective  in  our  analysis.  However,  removing  biases  proved  difficult  since  one 
of  the  researchers  was  formerly  the  assistant  product  manager  of  the  M-ATV. 
Additionally,  the  platforms  in  the  comparative  analysis  solely  came  from  a  single  PEO  of 
CS&CSS,  which  limited  our  sample  size  of  acquisition  programs  that  occurred  in  both 
the  RGPs.  Capabilities  documents  are  used  in  every  program  of  the  DoD  as  outlined  in 
the  JCIDS.  The  data  used  for  our  research  required  personal  interpretation  and  analysis 
as  Army  acquisition  officers  with  limited  experience  and  knowledge  based  on  our  current 
curriculums.  Our  interviews  were  structured  to  allow  the  SMEs  to  provide  input  based 
on  the  programs  they  had  experience  in  and  were  subjective,  which  may  have  led  to  some 
biases  in  the  results. 

Similar  research  could  be  conducted  by  modifying  our  research  methodology. 
Additional  research  could  analyze  the  efficiency  and  effectiveness  of  other  programs, 
whether  they  are  across  the  Army’s  Acquisition  Program  Offices  or  across  the  programs 
of  other  Services  in  the  DoD.  Additionally,  the  inclusion  of  TRADOC  would  also 
expand  the  scope  of  a  new  project.  This  would  provide  a  larger  sample  size  that  is  more 
expansive  and  compares  a  multitude  of  varying  programs  from  different  perspectives. 
Additionally,  a  comparative  analysis  could  also  be  done  with  non-like  items  or  materiel 
solutions  within  different  acquisition  categories. 

A  second  change  to  our  research  could  be  done  by  collecting  more  quantifiable 
data  such  as  cost  and  timelines  within  the  life  cycle.  The  sample  could  be  with  similar 
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materiel  solutions  that  have  life  cycles  within  the  same  calendar/fiscal  years  to  reduce  the 
variance  of  the  cost  analysis.  This  would  provide  another  means  for  analyzing  efficiency 
and  effectiveness  and  for  observing  whether  the  results  are  similar  or  different. 

2.  Other  Related  Proposed  Research  Topics 

We  have  conducted  a  great  deal  of  research  and  analysis  to  come  to  our 
conclusions  and  recommendations.  It  has  been  truly  a  learning  and  professional 
development  experience.  It  was  often  difficult  to  remain  on  one  path  since  a  great  deal  of 
the  information  provided  us  with  more  questions  in  regard  to  our  subject.  Consequently, 
here  are  some  areas  of  interest  for  future  research  based  on  our  study. 

The  first  area  for  additional  research  is  to  look  into  other  effects  that  occurred 
within  the  HMMWV  program.  There  are  two  areas  to  look  at  within  the  HMMWV 
program  as  possible  expanses  that  may  or  may  not  impact  the  efficiency  and 
effectiveness  of  the  program’s  requirements  documents.  The  first  area  is  the  program’s 
continued  use  of  RGS  requirements  documents  instead  of  transferring  to  JCIDS 
capabilities  documents.  Our  research  showed  the  program  continued  to  follow  RGS 
instead  of  changing  to  JCIDS.  The  question  then  becomes,  why  did  the  program  not 
change  to  MCDs  once  JCIDS  became  enacted?  The  second  area  deals  with  the 
recapitalization  program  that  occurred  for  HMMWVS.  This  provides  the  opportunity  to 
look  into  the  effects  that  any  documents  associated  with  the  recapitalization  program  may 
or  may  not  have  had  on  the  efficiency  and  effectiveness  of  the  requirements  documents. 

A  BBP  2.0  initiative  that  could  be  examined  on  the  impact  it  places  on  the 
efficiency  or  effectiveness  of  the  MRDs/MCDs  is  establish  stronger  professional 
qualification  requirements  for  all  acquisition  specialties  (Kendall,  2012).  We  originally 
planned  on  examined  this  initiative  for  effectiveness  of  MRDs/MCDs.  However,  after 
data  collection  and  analysis  we  determined  that  the  data  we  had  collected  to  support  this 
initiative  was  better  suited  towards  the  other  BBP  2.0  initiatives.  We  recommend 
conducting  an  analysis  of  the  level  of  certifications  with  CBTDEVs  and  PMs  to  examine 
the  effects  that  may  impact  the  MRDs/MCDs. 
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Analyze  the  average  time  it  takes  for  each  of  the  capabilities  documents  to  go 
from  initial  draft  to  JROC  approval  in  the  JCIDS.  As  we  learned  from  our  research,  there 
has  been  a  great  deal  of  variation  in  these  times  from  the  initial  implementation  of  the 
JCIDS  in  2003  to  the  present  date.  We  questioned,  What  were  the  driving  elements  that 
affected  the  documents  enroute  to  JROC  approval?  Was  it  urgency,  priority,  or  staffing? 
Was  it  internal  or  external  to  individual  stakeholders?  Or  was  it  the  result  it  the  result  of 
streamlining  changes  as  the  JCIDS  was  more  accepted  and  understood  within  the  DoD 
community?  We  propose  research  to  further  investigate  the  processes  of  requirements 
document  approval  within  the  RGP. 

Another  research  project  we  identified  while  examining  our  methodology  was 
effective  change  management.  In  regards  to  evolutionary  and  revolutionary  changes,  we 
questioned  if  the  change  from  the  RGS  to  JCIDS  was  effectively  implemented.  What 
resistance  was  encountered  when  implementing  the  JCIDS  and  what  were  the  effects  of 
that  resistance?  Why  were  there  so  many  versions  of  CJCSI  3170.01,  and  what  were  the 
factors  that  created  a  demand  for  so  many  evolutionary  changes  in  the  instruction?  This 
research  may  potentially  provide  better  methods  to  streamline  change  within  the  RGP  and 
the  DoD. 

A  fourth  topic  for  consideration  is  how  to  better  network  our  government  and 
defense  industry  within  the  sphere  of  the  RGP  and  how  to  manage  this  network.  There 
are  many  constraints  occurring,  such  as  budget  confidentiality,  downsizing  of  our 
military,  and  our  past  reliance  on  contractor  support.  Many  studies,  reports,  and 
investigations  have  been  published  in  regards  to  realigning  this  network  and  managing 
the  network  to  better  meet  the  public  interest.  However,  the  question  arises,  How  does 
the  DoD  and  the  acquisition  community  assist  in  this  initiative  without  surrendering  its 
sovereignty? 

A  final  topic  we  recognize  as  an  issue  was  the  impact  of  the  future  state  of  the 

nation  and  the  rapid  growth  of  technology.  The  current  National  Security  and  Defense 

Strategy  has  identified  that  the  great  magnitude  of  involvement  in  the  Central  Command 

AOR  is  slowly  decreasing  and  the  priority  shift  is  moving  towards  the  Pacific  Command 

AOR  (Obama,  2012).  A  new  capability  document  has  been  created  known  as  a  Joint 
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Emerging  Operational  Needs  Statement  (JEON)  and  is  now  in  CJCSI  3170.01H  (CJCS, 
2012).  What  are  the  concerns  and  considerations  that  the  RGP  may  face  in  this  future 
challenge?  How  will  technology  be  implemented  as  the  nation  and  DoD  shift  their  focus 
to  a  new  threat?  What  can  the  DoD  do  to  be  at  the  forefront  of  this  evolving  NSS?  This 
is  an  evolving  issue  for  which  the  DoD  must  prepare.  Answering  these  questions  is  one 
genuine  way  to  truly  serve  our  warfighters. 
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APPENDIX 


A.  INTERVIEW  QUESTIONS  FOR  PERSONNEL  AT  THE  PENTAGON 

Date:  Interviewee: 

Interviewer:  Anh  H.  Ha  &  Nathaniel  P.  Costa 

In  your  experience,  what  was  right  about  the  pre  2003  (pre  JCIDS)  “legacy” 
requirements  systems  process. 

In  your  experience,  what  was  wrong  about  the  pre  2003  (pre  JCIDS)  “legacy” 
requirements  systems  process. 

In  your  experience,  why  was  the  Joint  Capabilities  Integration  Development 
System  (JCIDS)  Process  created?\ 

In  your  experience,  were  their  certain  trends  within  the  DOD  /  Army  that  drove 
the  need  for  Joint  Capabilities  Integration  Development  System  (JCIDS)  Process? 

In  your  experience,  what  is  right  with  the  Joint  Capabilities  Integration 
Development  System  (JCIDS)  Process? 

In  your  experience,  what  is  wrong  with  the  Joint  Capabilities  Integration 
Development  System  (JCIDS)  Process? 

In  your  experience,  why  was  the  Joint  Urgent  Operational  Needs  System 
(JUONS)  /  Urgent  Operational  Needs  System  (UONS)  Process  created? 

In  your  experience,  what  is  right  with  the  Joint  Urgent  Operational  Needs  System 
(JUONS)  /  Urgent  Operational  Needs  System  (UONS)  Process? 

In  your  experience,  what  is  wrong  with  the  Joint  Urgent  Operational  Needs 
System  (JUONS)  /  Urgent  Operational  Needs  System  (UONS)  Process? 

In  your  experience,  what  do  you  feel  are  the  bottlenecks  in  the  Army  Materiel 
Requirements  Process?  Of  these  bottlenecks,  what  are  the  steps  that  should  be  eliminated 
or  what  actions  should  be  taken  to  begin  correcting  the  issues  to  streamline  the  process? 
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What  present  actions  are  being  identified  to  change  /  enhance  the  Army  materiel 
requirements  process? 

How  do  you  feel  the  Agile  Process  influence  /  effects  /  contributes  to  the  current 
Army  materiel  requirements  process? 

How  do  you  feel  the  Network  Integration  Evaluation  influence  /  effects  / 
contributes  to  the  current  Army  materiel  requirements  process? 

How  do  you  feel  the  System  of  Systems  Integration  (SOSI)  Directorate  influence  / 
effects  /  contributes  to  the  current  Army  materiel  requirements  process? 

How  do  you  feel  TRADOC  influences  /  effects  /  contributes  to  the  current  Army 
materiel  requirements  process? 

How  do  you  feel  TRADOC  should  influence  /  effect  /  contribute  to  the  future 
Army  materiel  requirements  process? 

How  do  you  feel  your  organization  should  influence  /  effect  /  contribute  to  the 
current  Army  materiel  requirements  process? 

How  has  the  current  Army  materiel  requirements  program  influenced  /  effected  / 
contributed  to  your  program  /  initiative  /  mission? 

How  do  you  feel  the  current  Army  materiel  requirements  program  has  influenced 
/  effected  /  contributed  to  your  program  /  initiative  /  mission? 

In  your  experience,  do  you  feel  the  Army  Materiel  Requirements  Process  should 
undergo  an  evolutionary  or  revolutionary  change?  Why? 

In  your  experience,  what  are  the  essential  elements  that  need  to  be  considered  in 
the  Army  Materiel  Requirements  Process  in  order  to  maximize  the  overall  efficiency  and 
effectiveness? 
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B.  U.S.  ARMY  TANK  AND  AUTOMATIVE  COMMAND  INTERVIEW 
QUESTIONS 

Rank: _  Name: _  Title  /  Position: _ 

In  your _ (duty  position),  what  is  the  MOST  important 

thing  that  must  come  from  a  MNS  /  ICD?  Why? 

In  your _ _  (duty  position),  what  is  the  LEAST  important 

thing  that  comes  from  a  MNS  /  ICD?  Why? 

In  your _ (duty  position),  what  is  the  MOST  important 

thing  that  must  come  from  a  CDD  /  ORD  -  Initial?  Why? 

In  your _ _  (duty  position),  what  is  the  LEAST  important 

thing  that  comes  from  a  CDD  /  ORD  -  Initial?  Why? 

In  your _ (duty  position),  what  is  the  MOST  important 

thing  that  must  come  from  a  CPD  /  ORD  -  Revised?  Why? 

In  your _ _  (duty  position),  what  is  the  LEAST  important 

thing  that  comes  from  a  CPD  /  ORD  -  Revised?  Why? 

Requirements  writers  lack  (Rank  Order) 

_  Acquisition  Knowledge 

_  Training 

_  Experience 

_  Other;  Comment: 

Do  you  feel  that  requirements  should  be  defined  by  (Rank  Order): 

_  Capability 

_  Threat 

_  Identified  system 

_  Other;  Comment: 
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How  beneficial  do  you  feel  each  document  is  for  providing  requirements?  (0, 
being  worst  -  10,  being  best)  _  MNS  _  ORD  _  ICD  _  CDD  _  CPD 

•  What  causes  the  “worst”  document  to  be  the  worst? 

•  What  causes  the  “best”  document  to  be  the  best? 

How  beneficial  do  you  feel  each  document  is  for  clarity  (easily  read  and 

understood)?  (0,  being  worst  -  10,  being  best)  _  MNS  _  ORD  _  ICD  _  CDD 

_  CPD 

•  What  causes  the  “worst”  document  to  be  the  worst? 

•  What  causes  the  “best”  document  to  be  the  best? 

How  useful  do  you  feel  each  document  is  within  the  RGP?  (0,  being  worst  -  10, 
being  best)  _  MNS  _  ORD  _  ICD  _  CDD  _  CPD 

•  What  causes  the  “worst”  document  to  be  the  worst? 

•  What  causes  the  “best”  document  to  be  the  best? 

How  beneficial  do  you  feel  each  document  is  for  providing  needed  information  to 
execute  the  document  for  the  appropriate  phase  of  the  acquisition  lifecycle?  (0,  being 
worst  -  10,  being  best)  __  MNS  _  ORD  _  ICD  _  CDD  _  CPD 

•  What  causes  the  “worst”  document  to  be  the  worst? 

•  What  causes  the  “best”  document  to  be  the  best? 

Rank  order  the  documents  from  most  useful  to  least  useful?  (1,  being  worst  -  5, 
being  best)  _  MNS  _  ORD  _  ICD  _  CDD  _  CPD 

•  What  causes  the  “worst”  document  to  be  the  worst? 

•  What  causes  the  “best”  document  to  be  the  best? 

How  well  do  requirement  documents  allow  the  ability  for  you  to  perform  your 
duties  based  on  the  four  key  functions  outlined  by  the  Army  Acquisition  Review  Board  in 
2011: 

•  Realign,  resource  and  focus  its  requirements  and  acquisition  professionals 
on  their  raison  d’etre  and  associated  core  competencies,  i.e.,  Training  and 
Doctrine  Command’s  timely  delivery  of  requirements;  PEO  and  Program 
Manager  delivery  of  products  meeting  the  requirement  on  cost  and  on 
schedule;  and  Army  staffs  that  are  accountable  for  enabling  the 
requirement  to  be  met 
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•  Involve  all  stakeholders  collaboratively  in  requirements  development, 
development  planning  and  acquisition  solicitation,  rather  than  just 
critiquing  others 

•  Realistically  assess  and  manage  risk,  and  follow  more  tailored 
evolutionary  acquisition  strategies  with  associated  reductions  in  steps, 
time  and  documentation  to  provide  new  systems 

•  Improve  the  number,  quality  and  accountability  of  the  people  essential  to 
the  acquisition  of  equipment  and  systems  needed  for  our  servicemen  and 
women  to  be  equipped,  trained  and  ready  (Army  Acquisition  Review 
Board,  2011,  p.  iv). 

•  What  could  be  changed  to  help  meet  these  requirements? 

What  key  differences  exist  in  the  documents  from  the  old  RGS  process  compared 
to  the  new  JCIDS  process,  and  what  is  your  understanding  for  why  these  changes 
occurred  during  this  transition? 

•  What  requirement  document(s)  do  you  feel  is  most  valuable?  And  why? 

•  When  comparing  RGS  documents  (MNS  and  ORD)  to  JCIDS  documents 
(ICD,  CDD,  CPD),  which  documents  do  you  prefer  or  mixture  of 
documents  do  you  prefer? 

•  What  are  your  reasons  for  picking  those  particular  documents? 

Which  document(s)  are  the  most  difficult  to  execute  for  JCIDS  and  RGS? 

•  What  causes  the  difficulty?  Organizations?  Missing  components  within 
the  documents?  Unnecessary  data? 

What  makes  requirement  documents  efficient  and  effective  for  the  stakeholders 
who  facilitate  the  RGP?  In  regards  to  the  program  office,  CMBTDEV  and  MATDEV. 

Are  CMBTDEV  providing  requirement  documents  with  adequate  detail  and 
requirements  that  are  clear,  concise  and  easily  understood? 

•  What  is  good? 

•  What  is  bad? 

•  Does  TRADOC  provide  enough  oversight  to  CMBTDEV? 

•  How  effective  and  efficient  is  communication  between  program  offices 

and  CMBTDEV  when  working  with  ICDs,  CDDs,  and  CPDs? 

Is  there  adequate  involvement  and  integration  between  CMBTDEV  and 
MATDEV  when  requirements  are  cross-walked  from  the  CPD  to  the  RFP? 
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•  Any  thoughts  on  how  the  documents  could  be  influenced  to  allow  for  a 
smoother  process 

•  How  effective  is  the  process? 

What  makes  requirement  documents  inefficient  and  ineffective  for  the 
stakeholders  who  facilitate  the  RGP? 

•  Do  you  feel  any  information  to  help  the  program  perform  its  function  is 
missing  in  the  requirement  documents?  If  so,  what  is  missing? 

•  How  difficult  or  easy  is  it  to  transpose  the  requirement  documents  to 
information  used  by  industry? 

•  How  much  interaction  and  follow  up  do  CMBTDEVs  provide  program 
offices  once  writing  and  submitting  a  requirement  document? 

Does  future  change  need  to  be  evolutionary  or  revolutionary  change? 

•  How  has  the  continued  modification  and  incremental  changes  of  the  RGP 
(CJCSI3170.01A  thru  H)  affected  you  or  your  program? 

•  What  observations  do  you  have  of  the  continually  changing  document  on 
the  acquisition  process? 

•  Do  the  continual  changes  impact  the  programs  in  a  positive  or  negative 
way  and  what  impacts  have  you  seen  or  experienced? 

Do  you  feel  that  JCIDS  needs  to  undergo  an  evolutionary  change  or  revolutionary 
change  to  support  the  Requirements  Generation  Process  post  GWOT? 

•  Evolutionary:  Maintain  JCIDS,  but  continue  refinement. 

•  Revolutionary:  Replace  JCIDS  with  another  Requirements  Generation 
Process. 

How  may  future  change  be  successfully  implemented  into  the  U.S.  Army? 

•  What  changes  would  you  recommend  for  requirement  documents  in 
general  and  or  for  a  specific  document? 

What  are  the  benefits  of  these  proposed  future  changes  to  these  capabilities 
documents? 
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INITIAL  DISTRIBUTION  LIST 


1.  Defense  Technical  Information  Center 
Ft.  Belvoir,  Virginia 

2.  Dudley  Knox  Library 
Naval  Postgraduate  School 
Monterey,  California 
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